As a perfect response to the objective of agility in application design, the process of continuous integration and delivery is gaining in importance. But if the CI/CD principle has proved its effectiveness over time, it's partly thanks to the tools that make continuous deployment possible. One of these tools is GCP Cloud Deploy. Find out how it works.
Everything you need to know about GCP Cloud Deploy
GCP Cloud Deploy is one of the many services on the Google Cloud Platform. The aim is to automatically deploy new code into production. In this way, all the tasks linked to the publication cycle of an application or software in the production environment are automated according to defined sequences. And all without human intervention. This service is fully in line with the DevOps movement, which involves continuous integration and deployment (CI/CD).
Good to know: Cloud Deploy lets you create deployment pipelines for GKE, Anthos and Cloud Run.
How do I deploy an application with Cloud Deploy?
As soon as a DevOps team makes changes to an application, it must transfer the new code to the Cloud Source Repositories. In order for these changes to be taken into account in the final version of the application, they must first create a first version of this update. This is where Google Cloud Deploy comes in, to manage its lifecycle through a distribution pipeline.
Defining the delivery pipeline and targets
The delivery pipeline contains a number of elements that are essential for the deployment of an application. Namely :
- The name and description: this is essential for referring to the pipeline.
- The promotion sequence: this defines the order in which all the deployment actions will be carried out.
- Targets: these are the environments in which the application will be deployed.
- For example, development (Dev), quality control (QA) and production (Prod). These targets are associated with an Anthos, GKE or Cloud Run cluster.
Good to know: Several pipelines can use the same target. However, the same target can only be integrated once into each pipeline. In addition, a pipeline can generate several versions and use several targets.
The broadcast pipeline is defined in the YAML configuration file. It then determines all the elements of the pipeline. A configuration file is also required for Scaffold. This file enables the GCP Cloud Deploy service to carry out rendering and deployment operations.
At this stage, you are not yet working on Google Cloud Deploy, but on Cloud Build. This is why you need to register it with the Cloud Deploy service, which will then be able to manage deployment to the target environments according to the defined sequence.
The call for release
The first step is to create a version of the changes made to the application or software. To do this, you need to call Cloud Deploy via the GCP console or API, and send it the compilation artefacts and references to specific container images.
GCP Cloud Deploy then stores a pipeline instance as part of the release. It then calls the YAML and Skaffold configuration files stored in cloud storage. It then creates a release resource. This is a manifest file for each environment.
💡Related articles:
The rollout call
Following this call to release, a rollout resource is automatically created. This initiates the delivery pipeline. The rollout resource is made up of several elements:
- Phases: this is a sub-message of the deployment. There are therefore several phases within the delivery pipeline.
- Tasks: these are the specific operations to ensure the application is deployed. Within a phase, there are one or more tasks.
- Task executions: these are the instances of the tasks. For example, a deployment attempt, a deployment, a validation, a validation attempt, etc.
All these elements have been previously defined in the promotion sequence.
The aim of the rollout is to associate the version with the first target environment. The modified application is then deployed on this first target.
Any CI tool capable of generating Docker images can be used to perform these various operations.
Promoting the application
Deploying the application on the other target environments involves a call for promotion. In other words, the completion of all the sequences defined upstream.
For each new promotion, the application is deployed on the next environment. All the way through to the last target environment (prod). In other words, the final application is put into production.
Other tasks performed by GCP Cloud Deploy
In addition to the Release, Rollout and Promotion processes, the delivery pipeline lifecycle involves a number of additional tasks. These include
- Approvals: to promote a pipeline to a new target, certain authorisations may be required. To do this, you generally need to use the IAM (Identify and Access Management) platform.
- Notifications: to facilitate the work of DevOps, Cloud Deploy sends several notifications to DevOps when certain events occur, such as rendering, deployment, approvals (required, approved or refused).
- The Pub/Sub service is used to send these notifications.
- Rollback: the idea is to trigger deployment of the latest version.
This is a simplified explanation of application deployment in GCP Cloud Deploy. If you want to go further in mastering this tool, training is essential. For that, there’s DataScientest. Our DevOps training course will teach you everything you need to know about the CI/CD process and how to use these tools.
Key facts:
- GCP Deploy manages the entire deployment process, enabling continuous integration and delivery.
- To use this tool, DevOps must first define the release pipeline by specifying its name, description, promotion sequence and target environments.
- The deployment process can then be initiated in three phases: release, rollout and promotion.
