CI is one thing CD is another. Let’s focus a bit on CD, and Deploy phase in particular from the "DevOps Loop". This sits squarely in the "Ops" category of DevOps. I’d like to expand on the concept, as there are several distinct steps that need to happen. Nothing is magical about it.

There are four practical steps that comprise Deploy:

1. Release of the software bits and configuration into a deployable package
2. Customization of that package to suit the target environment
3. Deployment of the package and validation of success
4. Cutover of users to the newly deployed release

Release

This step is distinct from the "Release" phase of the DevOps Loop. There the tested software is designated as a "Release" suitable for deploy phase. I would like to call out that software is released via many different package frameworks. It could be as a windows MSI bundle, as an OVA, or as a container and set of K8s manifests.

Regardless, the Ops side of your DevOps team needs to collect the bits and configuration into a package that fits the way your shop wants to automate deployment.

• Put the immutable newly released software artifact(s) into the proper deployment registry (which may not be the registry the Dev team "released them into!")
• Put the release deployment configuration into the proper registry
• Identify dependencies and repeat above for each
• Retrieve working copy of all configurations into assembly folder and arrange them into a standard (templated, parameterized) deployable package

Adapt

Great, the bits and pieces have been assembled into a deployable package for your needs, but into which environment will it be deployed? Will it be dev, test, stage, fix, pre-prod, or production? What public names will the services have? Will it be served by a load balancer or an ingress controller? Onto which IaaS? All of these questions and more lead into the need to adapt the standard release package to suite each specific target environment.

• Identify changes to configurations for the target environment
• Store configuration modifications to the release bundle preferably through parameterized custom values files or via overlays in the adaptations folder.
• Take the action of generating the final deployment configuration for the specific environment and place everything needed for deployment into deployment folder ready to execute.

Deploy

What tools do you use for deployment? Everything prior is about creating a package that suits the deployment toolchain. Now it’s time to execute. Who maintains that deployment automation? Where there is not automation, who steps through the process and how? How is the deploy monitored and remediated in case of failure? How is a successful deployment measured? Are there functional tests that must pass? The deployment phase is where all prior effort culminates into action distinct from the packaging phases prior.

• Roll out the deployment of the final configuration appropriately to the needs of the business (blue/green, rolling update, hard cutover, etc)
• Retrieve deployment logs from all activities
• Capture all configuration files and adaptations used to build the final deployment

Cutover

Deployment happened. You did a thing. Was that thing successful? Run additional testing over time to ensure successful release rollout. Things look good? Decide to cutover 100% to the new release deployment. Is something wrong? Roll back to previous versions. Automate the cutover or roll-back process as much as possible.

• Run functional tests to ensure successful deploy
• Execute final cutover automation once confirmation of deployment success is established
• Capture all deployment logs and artifacts into an immutable archive