Differentiate C Delivery and C Deployment?

[desktophero]

👋

I am curious if the minimums around CD should include language to differentiate delivery and deployment.

As an aspiring CI/CD practitioner, I've chosen to use a separate pipeline to help manage the flow of application code & config from the deployment code & config. Much of my experience is in large environments with many cross-team dependencies in the services space resulting in congruent constraints:

• Application code being trunk based development shouldn't care about deployment
• Business-aligned deployment doesn't map well to a pipeline - in terminology
• The separate deployment pipeline is still rooted in the same principles and practices of the application pipeline

The way I've chosen to describe this separate deployment pipeline is through a different deployment repo - a repo that addresses environment concerns, deployment strategies, and what (from the application pipeline) needs to be where (using releases).

There are plenty of pros and cons to any approach. I'm raising this issue up to see if there's an opportunity for a discussion from other others in the industry.

Thanks!

[bdfinst]

We are hoping for these kinds of conversations!

Continuous deployment is the superset that removes human decisions post-commit. My code merges and is either rejected from the pipeline or deployed to production. Since our goal is Minimum Viable CD, we encourage everyone to see this as the bare minimum to start seeing the organizational improvements we are after, but they should not stop here under any circumstances.

For CD to be effective, we are validating everything about the artifact, including the configuration of the application and the environment, work correctly. If you look at the recommended practices in the book "Continuous Delivery" CH. 5, you'll see that the single pipeline should be responsible for every activity, including deploy.

I also have experience working in VERY large environments. If there is a tightly coupled multi-team monolith, then CD is incredibly difficult. However, our goal isn't to add deploy automation to poor structure. Our goal is to use "why can't we do these practices today" as a lever to improve everything.

"Business-aligned deployment doesn't map well to a pipeline - in terminology" I think you're talking about separating release from deploy. This is where engineering practices are used for controlling the release of new features. We can release on demand and deploy continuously. This is a next-level practice that is highly recommended but not part of the MVP.

[ferrix]

Starting with continuous delivery was already tricky. Deployment is highly dependent on context.

[Jerreck]

I got to thinking about this when I was reading Gary's book yesterday and got to the part about deploying software for things like medical devices and airplanes. In that context, you can't really practice continuous deployment for a variety of reasons, but you could still practice continuous delivery. There's also a distinction between deployment and release when using feature flags for which we could maybe provide a distinction. If we did, those should probably go into a separate doc (maybe FAQ?) because at the end of the day we're defining bare minimum continuous delivery. Continuous deployment/release is a separate practice that doesn't always make sense in every context. All of that is based on my understanding of the terms/practices, though, and I've been wrong before :)

[bdfinst]

That's accurate and we discussed that during our ad hoc BoF sessions when we built this last week. You cannot continuously deploy to a submerged submarine because it's only in the network every 90 days or so. Not even to a Walmart store. Bandwidth budgets don't allow it.

[ferrix]

I think there are universal truths about Continuous Deployment that could be listed. However, since this is a minimal definitive list, I would not mix it with this set of constraints until we have a definitive list of context-conscious simple checkboxes. It would be confusing the readers if 3/4 are complete lists and 1/4 is a "these are the two-four irrevocable truths that will not work without a few context factors".