Live data from Hacker News

The development pipeline is a production system

sundry.jerryorr.com

51–60 of 98 posts

Re: The development pipeline is a production system

#51

Recently I heard a term "Software factory" - I am strongly rooting with this term, particularly while working with agents and AI. Heard from Vercel, Guillermo. "The (software) factory is the product. Your product is only as good as the agents you set up to autonomously maintain it." https://x.com/rauchg/status/2081123293340520642?s=20

Mechanized production was designed by people to produce commodities and was designed with planned tradeoffs, tolerances, and failure modes. That’s not what agents are, though I get why an analogy to the Industrial Revolution is useful for CEOs.

Re: The development pipeline is a production system

#52

Earlier quoted context omitted.

Not seeing this get traction, but this is exactly what I thought while reading this. The problem with calling something "a" top priority is you can only have one top priority. That's how priority works. A customer facing outage is a higher priority than a company-wide developer tool outage, which is higher priority than a single developer's personal workstation failing, etc. etc. That doesn't mean the lower-priority…

You need more than one team working outages. It’s not one team doing it all.

True. So you're talking about allocating resources (teams) across priorities. Which have to be prioritized. Which is the reality the article doesn't wrestle with at all.

Re: The development pipeline is a production system

#53
Yes but parts of it must live in the dev environment. CI by its very nature runs untrusted code. That is very hard to secure. Keep it away from production, production artifacts and production credentials. CI and CD should also be separate systems. The same system which builds and runs untrusted code should not have permission to push to production. Most of the industry uses a single system for CI/CD though. Good luck to you all.

Re: The development pipeline is a production system

#54
I’d bet there are as many stories of businesses failing because of inability to ship quickly as there are about focusing too much on your tooling instead of delivering value to customers. Both failures are dangerous! And depending on your market, product, team etc. a different spot on that spectrum is appropriate.

In some places shipping quickly is part of the value. In others, the product works and delivers value and having slow releases (implying eg a manual release process) is a feature.

What this article advocates for is certainly a valid lens, by IMO it’d be a mistake to take it as universal.

Re: The development pipeline is a production system

#56
post #22

> If the QA server is down, the testers are unable to do their jobs, and the team isn’t producing working software. For the QA team, this is a production outage. Fixing it should be a top priority. Genuine question, does anyone here ITT working in software still have dedicated QA? They laid off all our QA engineers about a year ago, and talking to friends and former colleagues it seems to be the industry wide trend?…

Worked for a company with a 3D web application (among other things.)

Those things can't be tested with Playwright et al. So the team had a "every pull request gets an instance like pr143.company.org" pipeline where QA approved. They must still have it.

The other companies tested "on demand."

Re: The development pipeline is a production system

#57
post #52

Earlier quoted context omitted.

You need more than one team working outages. It’s not one team doing it all.

True. So you're talking about allocating resources (teams) across priorities. Which have to be prioritized. Which is the reality the article doesn't wrestle with at all.

It doesn’t have to because the premise of the article is that development environments akin to manufacturing (eg software factories) need to be treated like Production. It’s a given that you have enough resources to handle both.

Re: The development pipeline is a production system

#58
post #49

Earlier quoted context omitted.

When we do updates, I mandate that our teams do blue/green deployments meaning they setup the exact VM side by side with the actual production data and test with the new version of software (eg GitLab) before doing the DNS flip. This is on prem. It’s an ephemeral sandbox.

I don’t think I’ve worked in an industry where it’s safe to use production data in a non-prod environment in probably 20 years. I think for dev, it’s fine not to have blue/green. You want dev deployments to be fast. UAT / pre-production/ or whatever your final env before prod — and particularly if stakeholders are intended to test on that env — is a different matter.

When I say Production, I mean Production Software Development data like Coverity or Fortify databases. GitLab source code and pipelines.

The premise is that Software Development is akin to Production which it should be.

Post reply on HN