Continuous Integration/Continuous Delivery (CI/CD) is the process of automating application updates, from changes in source control, to automated builds, to automated deployments to your servers. GCP provides a service for this, called Cloud Build.
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:
steps: - name: string args: [string, string, ...] env: [string, string, ...] dir: string id: string waitFor: [string, string, ...] entrypoint: string secretEnv: string volumes: object(Volume) timeout: string (Duration format) - name: string ... - name: string ... timeout: string (Duration format) queueTtl: string (Duration format) logsBucket: string options: env: [string, string, ...] secretEnv: string volumes: object(Volume) sourceProvenanceHash: enum(HashType) machineType: enum(MachineType) diskSizeGb: string (int64 format) substitutionOption: enum(SubstitutionOption) logStreamingOption: enum(LogStreamingOption) logging: enum(LoggingMode) substitutions: map (key: string, value: string) tags: [string, string, ...] secrets: object(Secret) images: - [string, string, ...] artifacts: object (Artifacts)
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:
steps: # Install dependencies - name: node entrypoint: npm args: ['install'] # Run tests - name: node entrypoint: npm args: ['test'] # Run custom commands - name: node entrypoint: npm args: ['run', 'build'] artifacts: objects: location: 'gs://mybucket/' paths: ['build']
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.
- › How to Use Your Apple Watch’s Hidden Web Browser (and Why You Shouldn’t)
- › Why Mario Kart Just Isn’t as Fun as It Used to Be
- › How to Batch Edit Photos and Videos on iPhone
- › 10 Alexa Features You Should Be Using on Your Amazon Echo
- › Why You Should Be Using ‘Movies Anywhere’
- › How to Test Your Computer’s PSU With a PSU Tester