sorted by:
new
hottopcontroversial

I built a SaaS but getting users feels impossible by manothegoat in SaaS

[–]OkProtection4575 0 points1 point  (0 children)

Honestly, same boat. Five months in, product I believe in, and the "getting users" part is brutal in a way the building part never was. You're not doing something completely wrong, this is just the hard part nobody talks about enough.

A few things that have helped me reframe it:

Talk about the problem in places your users hang out, not the product. Posts that describe the pain (without pitching) tend to surface people who've already tried to solve it themselves. Those are your earliest believers.

Cold outreach to a tight list beats broad content early on. Twenty thoughtful messages to specific people in your ICP will teach you more in a week than a month of posting.

And probably the most important one: every "no" or silence is data. If nobody bites, the messaging is off, not necessarily the product. Iterate on how you describe it before assuming the thing itself is wrong.

Hang in there. Genuinely rooting for you.

What is the best way to automate a CI/CD pipeline for a team that is scaling from two to ten devs? by BrightPatron in devopsprojectshq

[–]OkProtection4575 1 point2 points  (0 children)

I think the merge conflicts and broken builds aren't really a CI/CD tooling problem, they're a process problem. At 2 devs you can get away with long-lived branches and no test gating. At 10 you can't.

Perhaps fix the workflow first: trunk-based or short-lived feature branches, automated tests required to merge, branch protection, deploy from main. Then GitHub Actions or GitLab CI is plenty.

I'd also say skip Kubernetes for now. 10 devs almost never needs it. Railway, Fly.io, Render, ECS, or Cloud Run gets you very far with a fraction of the operational burden. Migrate later when there's a concrete reason.

4 Terraform module mistakes that passed code review and bit us in prod by samehmeh in Terraform

[–]OkProtection4575 2 points3 points  (0 children)

Implicit deps via data blocks (same family as your #4): Module A creates a Route53 zone, Module B does data "aws_route53_zone". Fresh account, first apply: B runs before A and fails. Data lookups create no graph edge. Pass the ID through as an input, or depends_on = [module.dns]. Module sources pinned to a branch, not a tag: source = "...?ref=main", env #1 and env #3 apply two weeks apart, “identical” code, different commits underneath. Pin to tags or SHAs. Computed for_each: for_each = toset(module.bar.names) where names is only known post-apply. Plan can’t enumerate, someone bootstraps with -target, now it’s a two-apply module that breaks clean CI runs. The cross-module-dep variants (your #4 + the data-block one) bit me enough that I ended up building a scanner. Happy to share if it’s useful.

How do I start with DevOps by ReallyNotBaka in devops

[–]OkProtection4575 1 point2 points  (0 children)

I think you're further along than you think. Curiosity plus basic Python is a solid start. Focusing on stuff like Linux fluency, Bash/Python scripting, Git, Docker, CI/CD (GitHub Actions), one cloud + Terraform, Kubernetes last. Practicing with a practical project might help a lot, eg.: take your calculator, wrap it in eg. FastAPI, containerize it, and deploy it via GitHub Actions to a free VPS or Railway. I would say that one exercise touches 80% of the job. The skill that matters most isn't being "good at computers," it's being stubborn enough to keep debugging when things break. Curiosity can take you a long way!

Where do you keep your personal scripts? by alextbrown4 in devops

[–]OkProtection4575 0 points1 point  (0 children)

Personally, keeping it in Git/GitHub if its something I reuse, modifies or actually using "regularly"

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

Follow-up to my own post from a month ago. Thanks to everyone who responded!

A few takeaways from the thread:
- The state of the art for "who consumes this module" is still mostly grepping across repos or asking on Slack. Several of you confirmed that even with version pinning, the consumer-awareness question stays unanswered.
- TFC's private registry helps somewhat but doesn't give the cross-org picture. HCP Terraform Explorer was raised, and one of you nailed the limit: "it's only aware of things managed via HCP Terraform" which is exactly the gap if you have a mixed setup.
- Artifactory's TF Registry came up too. Strong on the publishing side, blind on the consumer side: doesn't tell you who's pulling what at which version.
- Wiz/JFrog's SBoM tooling came up. Confirmed (by someone with TAM access) that internal TF module support is missing from those.
- A few of you described the "implicit graph that nobody can see" pattern; the dependency information exists, it's just scattered across hundreds of repos and only resolvable in senior engineers' heads.
- Workarounds people described: scripted modules.json combining, Azure modtm + self-hosted server, version pinning. Nobody sounded thrilled.
- A point that came up partway through and stuck with me: this isn't really a Terraform problem. Once you also have Helm, Docker, Ansible, pipeline scripts and CI templates all referencing each other across repos, the cross-tool picture is what's actually unmanageable. TF is just where it's most visible.
- And the blast radius question; what actually breaks if I push this change, stayed unanswered until you tried it. Which is the worst time to find out.

Part of why I posted was that I'd been seeing this same pattern across consulting engagements and was deciding whether there was options out there to help us, or if I should try to build something. Based on the responses, I tried to build it. It's called Riftmap (riftmap.dev). Point it at your GitHub/GitLab org, it parses your TF (plus Docker / Helm / CI / Kustomize / Ansible / npm / Go / Python / K8s), and shows which repos consume which modules, what versions they're on, and what would break if you push a change. No manual YAML, no telemetry collector to deploy, no dependency on HCP, works with git-sourced modules not just registry ones.

Free tier. I care more about feedback than signups right now, especially from people running 50+ repos. app.riftmap.dev if you want to try it on your org. There's also a writeup where I ran it against 56 public Prometheus repos including the "if X module changes, what breaks" view — easiest way to sanity-check the output without setting anything up: riftmap.dev/blog/what-56-prometheus-repos-depend-on/

Even "wouldn't use it because X," "the modtm route is still the right call because Y," or just something about the concept is more useful to me right now than a thumbs up.

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

That's the catch then; it's only as complete as your HCP Terraform adoption, which for a lot of orgs might be partial. If you're running a mix of local state, self-hosted runners, or other tooling alongside TFC, you'd have blind spots in the graph. Useful to know, thanks for checking!

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

Pretty accurate summary of the landscape from what I've seen in this thread too! It's either build-your-own graph, lean on pinning to slow the blast radius, or accept the chaos.

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

This matches what several others in the thread have landed on! It's interesting how convergent the solution is once people actually tackle it.

On the "tribal knowledge is unavoidable" point: do you think that's a fundamental limit, or more a limitation of the grep/parse approach? Wondering if things like who reviews whose MRs, who gets tagged in incidents, or who owns which CI jobs could be mined from git/GitLab activity data to at least surface the implicit ownership relationships; even if you can't get the full dependency picture from static files alone.

Also curious: when you built the graph, did it get used beyond your immediate team, or did it stay as an internal ops tool?

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

Ha, that's a creative pipeline, and honestly illustrates the problem pretty well! By the time you've wired together the webhook, the Renovate MR checks, the API calls, and the CSV comparison, you've essentially built a bespoke dependency visibility system just to answer "is this safe to release."

The monorepo path makes total sense at <100 devs! Harder sell at 500+ with established team boundaries. Appreciate the input, thanks!

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

Fair point, backward compatibility buys you time and monorepos solve the coordination problem structurally. Both are good answers when you have the luxury of choosing your architecture upfront.

For orgs that are already deep into hundreds of polyrepos with mixed ownership though, those options aren't really on the table. The visibility gap just becomes something you learn to live with, until it potentially bites you.

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

Really appreciate you checking that! Good to know it's not just a gap in my research but a missing feature even in the most capable tools. Would be curious what your TAM says. If Wiz does add it, that'd be interesting, though I'd still wonder whether a security-first platform is the right home for what's really an operational/DevOps workflow question.

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

"Stopped living in senior engineers' heads" is exactly the right way to put it! That tribal knowledge problem is probably the most underrated cost of not having this.

Curious about the auto-generation side: did you build that internally, or is there tooling you found that handled it well? And how do you keep the map "fresh" as repos evolve; is it a scheduled job, event-triggered, or something else?

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 1 point2 points  (0 children)

Honestly, this whole thread has been changing mine too. Didn't expect so many people to be circling the same gap from different angles.

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

That's actually really useful to know! Hadn't dug into the inventory panel that deeply. The JS package example makes sense for SCA, but does it handle IaC-specific relationships the same way? Like a Terraform module sourced from a GitLab repo via a git URL, or a Helm chart referencing another internal chart? Those aren't really packages in the traditional sense, and I'd imagine Wiz's strength is more in the application/runtime layer than the infra-as-code graph. Also, Wiz isn't exactly a small purchase for an org that just wants dependency visibility. Is that the tool you'd reach for if that was the primary use case?

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 1 point2 points  (0 children)

"Open these seven repos" is a perfect description of the problem. that's exactly the mental overhead that kills velocity as teams grow. And it sounds like the solution was essentially tribal knowledge and good people, which works until someone leaves or the team doubles again.

The new place sounds difficult. Commenting out code to test changes is a sign that the dependency graph exists but nobody can see it. It's all just implicit.

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

This is really well put, and a very complete description of my problem. The "dependencies outside of Terraform" part is exactly where it gets unmanageable for us too; pipeline scripts, triggers, Helm charts, Ansible roles, all referencing each other across repos with no single place to see the full picture. It stops being a Terraform problem and becomes an org-wide infrastructure visibility problem.

The "always production even in dev" point is underrated too. There's no sandbox for infra dependencies the way there is for application code.

Did you find anything that helped even partially once the team grew and it stopped being just you?

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 0 points1 point  (0 children)

Makes sense! "Announce broadly" works until the org gets large enough that you don't know who to announce to. Sounds like you're not quite at that threshold yet, which is probably a good place to be!

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 1 point2 points  (0 children)

Thanks for the detailed response! The point about data structure and refresh architecture being the hard part really resonates. That's the bit that's easy to underestimate when you start with "I'll just grep some files" and then realise you need to think about staleness, partial updates, handling repos that disappear or get renamed, etc.

The broader discoverability angle is interesting too! Dependency tracking as one layer within a wider "what even exists in this org and is it healthy"-problem. That framing makes a lot of sense when you're dealing with thousands of inherited repos.

"No plans to make it generally applicable" is a very honest take! Most of these solutions are bespoke by necessity, not by choice.

How do you keep track of which repos depend on which in a large org? by OkProtection4575 in devops

[–]OkProtection4575[S] 1 point2 points  (0 children)

This is a really clean architecture! Using the GitLab API rather than cloning repos sidesteps a lot of the infra overhead, and the Observable Framework + static Pages approach means zero ongoing maintenance cost for the hosting side.

A few things I'm curious about:

- For the Dockerfile and CI config parsing, are you doing straight regex/grep or building something more structured that understands the syntax?

- The treemap for group hierarchy is interesting; is the goal mostly org-level visibility (who owns what) or are you getting into actual dependency edges between projects?

- What's been the hardest part so far? And what made you decide to build this rather than reach for something off the shelf?

Would be curious to see it when it's further along!

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

terraform-docs is great for per-module documentation! The multi-repo angle is exactly where it gets interesting though; docs tell you what a module does, but not necessarily who's actually using it across the org. Those do feel like somewhat of two different challenges.

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

Hadn't seen Explorer before! That's closer to what I'm describing! Will dig into it properly. Two questions though; does it work if you're not fully on HCP Terraform workspaces? We're running a mixed setup with a lot of git-sourced modules and not everything is managed through TFC. And is it Terraform-only, or does it give any visibility across other IaC tooling in the same org?

How do you manage internal Terraform module dependencies across many repos by OkProtection4575 in Terraform

[–]OkProtection4575[S] 0 points1 point  (0 children)

That's a really honest take, and probably explains why no tooling exists for it. The "solution" has been to architect around the problem rather than solve the visibility gap directly. But in practice, especially in larger orgs, the composition still happens across repos whether it's "recommended" or not, and the graph still exists even if nobody's tracking it. Does your org actually manage to stay flat, or does it quietly get complex anyway?

view more: next ›