Continuous Delivery/Continuous Deployment with BitBucket Pipelines

Overview

Teaching: 15 min
Exercises: 30 min

Questions

• How can I set up Continuous Deployment/Continuous Delivery in BitBucket Pipelines?

Objectives

• Understand how to set up Continuous Deployment/Continuous Delivery in BitBucket Pipelines

Setting up a BitBucket Pipeline to deploy an application

To understand how to set up Continuous Delivery or Continuous Deployment with BitBucket Pipelines we will look at the BitBucket Pipeline template to deploy a React application to AWS.

You do not need to understand the specific details of react, node.js or AWS. It is more important that you understand the general setup of such a deployment pipeline. The same kind of setup can be used for any application written in any language deployed to any on-premise or cloud server. To keep secrets like SSH keys out of public files, they can be stored in repository variables

Exercise: Deploying a React application

Have a look at below bitbucket-pipelines.yml file. Read through it and try to understand what is happening at each step.

1. Can you define the 4 steps that are defined in the pipeline? One of the steps is in there twice.
2. Can you spot the differences between the 2 ‘Build and Test’ steps? In which situations is the one used and in which the other?
3. What do you think is ment with artifacts? Can you see where the artifact stored of the master-branch ‘Build and Test’ step is used?
4. Is this a Continuous Deployment or Continuous Delivery setup? Why?
5. Where do variables such as $AWS_ACCESS_KEY_ID come from?
6. Think of a project in which an application is regularly updated and deployed. Could the project benefit from using such a BitBucket Pipeline?

#  Template React Deploy

#  This template allows you to deploy your React app to an AWS S3 bucket and invalidate the old AWS Cloudfront distribution.
#  The workflow allows running tests, code linting and security scans on feature branches (as well as master).
#  The react app will be validated, deployed to S3 and trigger an AWS Cloudfront distribution invalidation to refresh the CDN caches after the code is merged to master.

# Prerequisites: $AWS_ACCESS_KEY_ID, $AWS_SECRET_ACCESS_KEY setup in the Deployment variables.
# For advanced cases, please, follow examples from the pipe's:
# README https://bitbucket.org/atlassian/aws-s3-deploy/src/master/README.md
# README https://bitbucket.org/atlassian/aws-cloudfront-invalidate/src/master/README.md

image: node:16

# Workflow Configuration

pipelines:
  default:
    - parallel:
      - step:
          name: Build and Test
          caches:
            - node
          script:
            - npm install
            # CI=true in default variables for Bitbucket Pipelines https://support.atlassian.com/bitbucket-cloud/docs/variables-in-pipelines/
            - npm test
      - step:
          name: Lint the node package
          script:
            # Run your linter of choice here
            - npm install eslint
            - npx eslint src
          caches:
            - node
  branches:
    master:
      - parallel:
        - step:
            name: Build and Test
            caches:
              - node
            script:
              - npm install
              # CI=true in default variables for Bitbucket Pipelines https://support.atlassian.com/bitbucket-cloud/docs/variables-in-pipelines/
              - npm test
              - npm run build
            artifacts:
              - build/**
        - step:
            name: Security Scan
            script:
              # Run a security scan for sensitive data.
              # See more security tools at https://bitbucket.org/product/features/pipelines/integrations?&category=security
              - pipe: atlassian/git-secrets-scan:0.5.1
      - step:
          name: Deploy to Production
          deployment: Production
          trigger: manual
          clone:
            enabled: false
          script:
            # sync your files to S3
            - pipe: atlassian/aws-s3-deploy:1.1.0
              variables:
                AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
                S3_BUCKET: 'my-bucket-name'
                LOCAL_PATH: 'build'
            # triggering a distribution invalidation to refresh the CDN caches
            - pipe: atlassian/aws-cloudfront-invalidate:0.6.0
              variables:
                AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
                AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
                AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
                DISTRIBUTION_ID: '123xyz'

Solution

1. The 4 steps are: Build and Test, Lint the node package, Security Scan, and Deploy to Production.
2. The top ‘Build and Test’ step first installs the application, then tests it. The bottom ‘Build and Test’ step also builds the application and stores the build in an artifact. The top ‘Build and Test’ step is run in all branches apart from master. The bottom ‘Build and Test’ step is only run on the master branch.
3. artifacts are files stored within one step and used in another step. It is used again in the sync your files to S3 script where LOCAL_PATH refers to the ‘build’ folder.
4. This is a Continuous Delivery setup, because the step to deploy to production is manual.
5. These are Deployment variables defined in the settings of your repository or organisation, read more here: https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/
6. Discuss with other participants!

Key Points

• You can configure automated deployment in the bitbucket-pipelines.yml file