One of the biggest misconceptions in platforms I’ve seen is the attempt to combine CI/CD into the same business and technical process. Its really tempting and dangerous. https://www.prodvana.io/blog/ci-cd-joined-forever-never-the-same

Very interesting article. you put words and diagrams on something I am struggle with. Thank you so much for this article.

thanks happy to chat more or go deeper in places if needed - we try and write something useful on this subject once a week right now

I don’t have someone in mind. My point was to +1 your words about the misconception between CI and CD. Lots of people toalk about CI/CD pipelines while Pipelines are most of the time the CI part, CD is another flow to deplow (sometimes for CD you also need to re-run a CI dedicated to the infrastructure layer).

would you be interested if we put together a zoom roundtable?

Yes sure. I am based in France (for timezone management)

Super interesting article Andrew! Thanks for sharing ✌️

One of the things that further blurs this picture is when you do not have all of your infrastructure in code and the systems under management have multiple change vectors. This adds complexity to the automation since you constantly need to check state as part of your deployment process

@Dan Capetta we’ve got thoughts on how to solve that 🙂 IaC for everything is a nice north star but my experience w/ large scale systems tells me there has to be compensating controls. We do that via a mechanism we call “Protections” - https://www.prodvana.io/blog/convergence-deployment-engine-intro - the reality is that all the tech in deployments is built for a world that predates distributed systems being the norm. Pipelines are a big part of the problem…

I read your article. You arise a very interesting concept. CI and CD should be treated different because they are different. Agree. But what is the proposed approach? Is a methodological or a technological one? For instance, when doing CI, tools like Selenium are used and when doing CD, I use new tools like Spacelift precisely to solve the infra drift always happening problem. But it is also true that I never thought about creating different principles for CI and CD. Conclusion.... how do we approach this challenge? Methodologically, Technologically, both? Any real example? Thanks for the contribuition!

It has to be both. Most organizations actually have these be different at scale. In my previous role as VP Infra @ Dropbox I had two different teams responsible for the workflow: developer infrastructure and production infrastructure. (~250-300 for my org, 1k in all of eng - there were other teams too not 250 people for just this) • Dev Infra had to reduce friction from developer to validate as fast as possible • Production Infra had to put the appropriate guardrails in to deploy at the rate the business needed with the guardrails the business needed Additionally development tends to be a 1 of problem vs production which is an N of problem. The tech is drastically different and the mistake is try and mix them. The ability to prioritize is also very important. A DevInfra leader optimizes for velocity while a Prod Infra leader will optimize for reliability. The tradeoff at a junior level typically doesn’t work well - scope for most orgs ends up at Director for each of these roles. You need leaders that can effectively make tradeoffs and communicate them when you’re dealing w/ Prod <> Dev. In larger orgs it might be VP that roles up to a SVP of Platforms/Infrastructure whatever the current buzz word is. I tend to like leaders to have to optimize for one key metric until VP+ where that is the job. There’s a reason Directors are called Directors - they are the operators/execution driver.

I was reading yesterday your golden path. It is in my bookmarks to study it carefully. Thanks 😉

i personally find the way the ref arch and paths are communicated by most in the community are so vendor and setup specific. I prefer operate off principles and give leeway to the teams to execute