The Continuous Delivery Test
sourceless.org
The Continuous Delivery Test
1–10 of 72 posts
Re: The Continuous Delivery Test
#2This feels like yet more cargo-culting.
Even the first item on this list is hotly contested, with Facebook/Microsoft/Google and Co. using centralised mono-repos, google itself using a server model similar to Perforce called Piper.
To be clear here, I’m not saying they’re right, but with it feels un-scientific to make a blanket statement that they’re wrong.
Re: The Continuous Delivery Test
#3This feels like yet more cargo-culting. Even the first item on this list is hotly contested, with Facebook/Microsoft/Google and Co. using centralised mono-repos, google itself using a server model similar to Perforce called Piper. To be clear here, I’m not saying they’re right, but with it feels un-scientific to make a blanket statement that they’re wrong.
You can easily have a monorepo with a distributed control system.
Re: The Continuous Delivery Test
#4This feels like yet more cargo-culting. Even the first item on this list is hotly contested, with Facebook/Microsoft/Google and Co. using centralised mono-repos, google itself using a server model similar to Perforce called Piper. To be clear here, I’m not saying they’re right, but with it feels un-scientific to make a blanket statement that they’re wrong.
You can easily have a monorepo with a distributed control system.
Yes. But I’m referring to the article:
> 1. Do you use a distributed version control system?
Edit: the parent originally said “distributed build system”
Re: The Continuous Delivery Test
#5Earlier quoted context omitted.
You can easily have a monorepo with a distributed control system.
Yes. But I’m referring to the article: > 1. Do you use a distributed version control system? Edit: the parent originally said “distributed build system”
Just because it's a monorepo it doesn't mean it's centralized?
Re: The Continuous Delivery Test
#6Earlier quoted context omitted.
You can easily have a monorepo with a distributed control system.
Yes. But I’m referring to the article: > 1. Do you use a distributed version control system? Edit: the parent originally said “distributed build system”
I'm not sure what you're getting at here. Mono-repo is entirely a different concept then centralized (eg: SVN) vs distributed (eg: git).
I'd also seriously question an org not using git, specifically, despite claiming "cargo cult". Literally every developer knows it, it's got a huge choice of tooling, and every service/tool (CI/CD, issue tracker, etc) has an integration. IMHO, you better have a damn good reason to be on something else to justify the headaches involved of being not git.
Re: The Continuous Delivery Test
#7Earlier quoted context omitted.
You can easily have a monorepo with a distributed control system.
Yes. But I’m referring to the article: > 1. Do you use a distributed version control system? Edit: the parent originally said “distributed build system”
Read this as “Do you use git?” This is opposed to svn, cvs, something home-grown, or passing thumb drives back and forth among developers.
Re: The Continuous Delivery Test
#8> 9. Does your Infrastructure as Code live alongside the service it hosts?
That means minor changes to some test infrastructure have to go through the strict review process, because the gitlab-ci.yaml is in the part of the main code. Last time this happened to me I found it annoying, and I don't think the code quality guardians care about some CI config anyway.
Re: The Continuous Delivery Test
#9Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.
Re: The Continuous Delivery Test
#10> 11. Do you include ticket IDs in your commits or branches?
This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits).
In the wild this devolves into a meaningless umbrella issue (Deliver Feature Foo) or 1 liner issues that sometimes did not even match the pr contents.
Just use the commit message and in pr review enforce commit message norms.