Continuous Integration and Delivery (CI/CD) is a process of ensuring that software is up-to-date and working correctly by integrating it with other software systems. It can be used to improve the quality of software, reduce the time it takes to develop and deploy software, or improve the reliability of software. There are many ways to get started with CI/CD on Google Cloud Platform. You can use the Google Cloud Platform Console to create a project, set up an environment, and start testing. You can also use the Google Cloud Platform CLI to manage your CI/CD tasks. To get started with CI/CD on Google Cloud Platform, you first need to create a project. To do this, you use the Google Cloud Platform Console. In the Console, click on New Project . In the Project Name field, enter a name for your project. In the Type field, choose either an application or platform project. In the Environment field, choose which environment you want to build your project in: public or private cloud instances. In the Build Phase field, specify how you want your project built: as a stand-alone application or as part of a larger application that uses other parts of Google Cloud Platform. Click on Finish . You can now start building your project by using one of several tools in the Google Cloud Platform CLI: build , test , deploy , and run . The build tool will create files in your project directory that will be used for building your application or platform projects. The test tool will run tests against your applications and platforms to check whether they are working correctly. The deploy tool will create files in yourproject directory that will be used for deploying your applications or platforms into different environments on Google Compute Engine (GCE). The run tool will run these deployments automatically when you push changes to your repository using GCP commands such as gcloud commit . If you have questions about how CI/CD works or want help getting started,
Writing a Build Configuration
The CI/CD pipeline featured here works pretty simply. GCP listens for changes in your source control, either new commits on a specific branch, or new pull requests. Then, it sends the source to Cloud Build, which runs a set of commands to test and build the application, and sends the output build artifacts over to App Engine, GKE, Cloud Functions, or a Cloud Storage bucket.
Most of the configuration for Cloud Build actually happens outside of Cloud Build, in a YAML file called cloudbuild.yaml. This defines the build steps, options, and output settings. The schema looks something like this:
You won’t need all of these options though. A simple configuration like the following will build an NPM application and deploy it to a Cloud Storage bucket:
The first key, “Steps,” runs npm install to get dependencies in order, then npm test to run any tests you have set up, then npm run build to start the build process. After that completes, output artifacts in the build folder are sent to gs://mybucket/. You don’t have to deploy to an output bucket though; Cloud Build supports deployments to GKE, Cloud Functions and Cloud Run, and App Engine.
Ultimately though, this step will highly depend on what kind of application you’re building, so we can’t write a step-by-step guide for everyone. We recommend reading Google’s configuration overview to learn more.
Setting Up Cloud Source & Cloud Build
Once you have a build configuration, you can set up Cloud Build to handle the actual builds. Cloud Build gets its source from Cloud Source, Google’s own hosted Git solution. If you want to use your own git though, you can link an external account, or just set up Cloud Source as a secondary release remote.
Head over to Cloud Source and create a new repository. You can sign in with Github or Bitbucket to link an external account and select a repository, or just create a new one and add it as a secondary remote.
Head over to Cloud Build, and click “Set Up Build Trigger” from the dashboard.
Give it a name, select the source repository, and choose when you want this trigger to run. You can trigger based on commits to a certain branch, new tags, or pull requests. You can also use regex to match the branch names.
You’ll want to keep the default here for the Cloud Build configuration file, but if you gave it a different name or placed it under a different path, you can select that here. You also have the option of setting custom variables, which will let you re-use configuration with multiple triggers on different branches.
Click create, and the trigger will appear in the dashboard. You can manually run the trigger here to test your settings.
Once it’s set up though, it will run automatically on every push to the branch, or pull request, depending on what you configured.
