Ten years of deploying to production
27 points
2 days ago
| 2 comments
| brandonvin.github.io
| HN
andersmurphy
51 minutes ago
[-]
> In that decade, this company was behind the curve

I like to think there is no curve only fashion. I've seen company's that were so behind that they managed to avoid adopting disasters like microservices etc. I've seen companies ahead of the curve go from monolith to microservices back to monolith.

Also funny that the ops team is now back just rebranded as the platform team.

Plus ça change.

reply
icameron
1 hour ago
[-]
That’s a tough policy to only update prod biweekly! It would be super frustrating if you had a bug crawl out and not be allowed to patch it for 2 weeks. This post really expresses the frustration of working in a bureaucratic environment where developers don’t have full access to change production.

That being said CI/CD is a luxury for coders at lean startups, but there’s still a lot of jobs where you have to work with some DevOps Team to deploy your code to prod. Organizations past a certain size have more hoops to jump through, for reasons.

Of course as a dev it’s ideal to have full access!

reply
ozim
38 minutes ago
[-]
You know that making CI/CD doesn’t mean you have to pay boatloads of money to a vendor.

Putting up bash script that pulls repo and deploys it is already CI/CD.

Setting up basic Jenkins installation for a technical person should not be taking longer than 2 hours. For person who already is familiar with Jenkins that would be 30mins.

Once you have paying customers I would say there should be max and minimum 2 devs that can fiddle with prod. Others should pass changes via senior people.

reply