This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

C

Continuous Integration and Continuous Delivery (CI/CD)

As cloud native approaches gather steam, CI/CD practices have to evolve to maintain stability as you increase speed. Because without the right guard rails, it’s like attaching a rocket ship to a go kart. It’s not a very fun ride.

- Ravi Tharisayi, ex-Team Lead and Principal Advisor at IBM

Continuous Integration (CI) and Continuous Delivery (CD) embody a culture, set of operating principles, and collection of practices that enable application development teams to deliver code changes more frequently and reliably. The implementation is also known as the CI/CD pipeline.

CI/CD tools help store the environment-specific parameters that must be packaged with each delivery. CI/CD automation then performs any necessary service calls to web servers, databases, and other services that may need to be restarted or follow other procedures when applications are deployed.

Continuous Integration

It is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. Because most modern applications require developing code in different platforms and tools, the team needs a mechanism to integrate and validate its changes.

The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.

Continuous Delivery 

CD picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments. Most teams work with multiple environments other than the production, such as development and testing environments, and CD ensures there is an automated way to push code changes to them.

A typical CD pipeline has build, test, and deploy stages. More sophisticated pipelines include many of these steps:

  • Pulling code from version control and executing a build.
  • Executing any required infrastructure steps that are automated as code to stand up or tear down cloud infrastructure.
  • Moving code to the target computing environment.
  • Managing the environment variables and configuring them for the target environment.
  • Pushing application components to their appropriate services, such as web servers, API services, and database services.
  • Executing any steps required to restarts services or call service endpoints that are needed for new code pushes.
  • Executing continuous tests and rollback environments if tests fail.
  • Providing log data and alerts on the state of the delivery

Implementing CI/CD pipelines with Kubernetes and serverless architectures 

Many teams operating CI/CD pipelines in cloud environments also use containers such as Docker and orchestration systems such as Kubernetes. Containers allow for packaging and shipping applications in standard, portable ways. Containers make it easy to scale up or tear down environments that have variable workloads.

There are many approaches to using containers, infrastructure as code, and CI/CD pipelines together. You can explore options such as Kubernetes with Jenkins or Kubernetes with Azure DevOps.

Serverless computing architectures present another avenue for deploying and scaling applications. In a serverless environment, the infrastructure is fully managed by the cloud service provider and the application consumes resources as needed based on its configuration.

1 - Cloud Build by Google Cloud Platform

Use GCP Cloud Build to build, test and deploy container images.

Implementing containerization has inspired organizations to maximize managed cloud infrastructures like Cloud Build to speedily build, test and deploy container images.

Cloud Build is a service that executes your builds on Google Cloud.

Cloud Build can import source code from a variety of repositories or cloud storage spaces, execute a build to your specifications, and produce artifacts such as Docker containers or Java archives.

Learn

Learn more about Cloud build in GCP from the official documentation.

Try out Continuous deployment to Google Kubernetes Engine (GKE) with Cloud Build from this codelab

2 - Containers

About Containers and their uses.

Containers are lightweight packages of your application code together with dependencies such as specific versions of programming language runtimes and libraries required to run your software services.

What are containers?

Containers are packages of software that contain all of the necessary elements to run in any environment. In this way, containers virtualize the operating system and run anywhere, from a private data center to the public cloud or even on a developer’s personal laptop. From Gmail to YouTube to Search, everything at Google runs in containers. Containerization allows our development teams to move fast, deploy software efficiently, and operate at an unprecedented scale.

What are containers used for?

Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data center, the public cloud, or even a developer’s personal laptop.

  • Microservices:

    Containers are small and lightweight, which makes them a good match for microservice architectures where applications are constructed of many, loosely coupled and independently deployable smaller services.

  • DevOps:

    The combination of microservices as an architecture and containers as a platform is a common foundation for many teams that embrace DevOps as the way they build, ship and run software.

  • Hybrid, multi-cloud:

    Because containers can run consistently anywhere, across laptop, on-premises and cloud environments, they are an ideal underlying architecture for hybrid cloud and multicloud scenarios where organizations find themselves operating across a mix of multiple public clouds in combination with their own data center.

  • Application modernizing and migration:

    One of the most common approaches to application modernization starts by containerizing them so that they can be migrated to the cloud.