Once a developer is ready to ship their code, the work of shipping safely without breaking things means understanding and adopting a number of delivery concepts. Many of these, such as continuous integration/continuous delivery (CI/CD), are familiar to most developers, while others, such as continuous deployment, progressive delivery and experiment-oriented rollout techniques may be less familiar. Gaining an understanding of these concepts forms the basis for this next step in owning the full development lifecycle.

Shipping code safely relies on a number of delivery practices, and most software developers have experience with continuous integration/continuous delivery (CI/CD) regardless of their application architecture or target deployment platform/infrastructure. However, with the increasing adoption of cloud native technologies and approaches, CI/CD is evolving to include progressive delivery and continuous deployment, which automate deployment and release and contribute to giving developers faster feedback loops and safer deployments.

CI/CD is a familiar pattern for getting changes to features, configuration, bug fixes, and so on, into production safely. If these principles are already well-understood, progressive delivery and continuous deployment will be logical extensions to the delivery and deployment landscape.

Continuous integration/continuous delivery (CI/CD) form a combined practice of integrating and delivering code continuously into a production environment. CI/CD is a well-known practice in developer circles.

Continuous integration (CI) is an automation process and development practice that lets teams of developers introduce code changes to an application, run test suites for quality assurance, and build software artifacts on a continuous basis.

Continuous delivery (CD) is a process that introduces changes, from artifacts and version updates to configuration changes, into a production environment as safely as possible. When continuous delivery changes are made, these changes rely on a human decision.

Developing for fast-moving, cloud-native environments poses new challenges that increasingly call for something more than continuous delivery. Delivering larger sets of microservice-based applications at an increasing velocity, traditional CD is often not often enough to maintain the speed required at an acceptable risk level. The combination of independent service teams all building and releasing concurrently, and multiple services collaborating at runtime to provide business functionality can slow things down and create friction.

Continuous deployment is a software release process that uses automated integration and end-to-end testing to validate changes, along with the observability of the system’s health signals, to autonomously change the state of a production environment.

Continuous deployment extends continuous delivery. While both CDs are automated, humans do not intervene in continuous deployment. Deployment and release happen automatically, and the only way a change won't be deployed to production is if an automated check fails.
With continuous deployment, developers can get their code into real-world conditions and benefit from faster feedback loops, better decision-making, and the ability to safely deploy more code.

A CI/CD pipeline is a process specifying steps that must be taken to deliver a new version of the software. A CI/CI pipeline consists of workflows, activities, and automation. Automation is key to scaling CD, accelerating application delivery, and making developers' lives easier in the cloud-native environment. For cloud native developers, GitOps is central to the evolution of CI/CD.

GitOps is an approach to continuous deployment that relies on source control as a single source of truth for all infrastructure and configuration for a Kubernetes deployment. The source code itself as well as deployment metadata that describe how the application should run inside the cluster live within this source control system.

In the GitOps model, configuration changes go through a specific pull-based workflow:

• All configuration is stored in source control. The Git repository is the source of truth.
• A configuration change is made via pull request.
• The pull request is approved and merged into the production branch.
• Automated systems (e.g., a build pipeline or Kubernetes Operator) ensure the configuration of the production branch is in full sync with actual production systems.

Changes are automated via the source control system; GitOps enables Kubernetes clusters themselves to "pull" updates from source control manifests. The entire GitOps workflow is also self-service; an operations team does not need to be directly involved in managing the change process (except in the review/approval process).

The idea of GitOps for developers is to allow for ease of use: a developer writes code, sends a pull request via a version control system, it's reviewed by another person, and from there, there is no further human interaction. The rollout is automated in a GitOps workflow, in the form, for example, of a canary deployment using a tool like Argo, a declarative, GitOps CD tool for Kubernetes.

• Watch:
  • 3:14-5:37 of this "Continuous Delivery with Docker and Java" DockerCon 18 talk​
• Read the following articles:
  • The first half of this Google article (and stop reading when you reach "Organizational Model"):
  • GitOps​

Move on to the next lesson!