Continuous Deployment with Pipeline as Code – CircleCI

by Benjamin Lallement, DevOps and member of the collective Gologic.

Goals Series

This article series aims to explore the different tools for doing pipeline-as-code and deployment.

The goal for each article remains the same: Checkout GIT source code, compile a JAVA project with Maven, run the tests then deploy the application on AWS BeanStalk.

Those steps will be written as code in a pipeline and executed with a CI/CD tools.

Each article is divided into several parts:

Installation and startup of a CI/CD tool
Configuration CI/CD tool (if needed)
Code continuous deployment pipeline
Check deployment
A simple Conclusion

If you want to run pipeline, you will need:

Docker runtime to execute pipeline steps
An AWS BeanStalk environment with access key and secret to deploy the application

Before starting, let’s define two key concepts: Continuous Deployment and Pipeline-As-Code.

What does “Continuous Deployment” mean?

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.

“Essentially, it is the practice of releasing every good build to users”, explains Jez Humble, author of Continuous Delivery.

By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software.

With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fuelling real change in your organization, and turning your release process into a business advantage.

What does “Pipeline as Code” mean?

Teams are pushing for automation across their environments(testing), including their development infrastructure.

Pipelines as code is defining the deployment pipeline through code instead of configuring a running CI/CD tool.

Source code

GitHub Demo Reference is there: Continuous Deployment Demo

CircleCI

Goal

For this fourth article, CircleCI is our designated volunteer. You’ll find the first, second and third article by clicking here: #1-Jenkins, #2-Concourse, #3-GitLab

CircleCI is a continuous integration engine proposed in SaaS mode. The 2.0 version of CircleCI supports workflows to simplify the sequence of pipeline stages. It is now possible to install pipelines with a MacOS and Linux compatible client.

In this article, we present the configuration of a pipeline. The CircleCI pipeline function works as a YAML descriptor, the configuration is stored in the project as .circleci/config.yml file.

CircleCI integrates very easily with a GitHub project, however, it is impossible to view with a repository that is not accessible publicly. The GitHub project is configured in the project as well, the pipeline is started during a source code change on a branch, so this is a change in the the source code or the pipeline itself.

A Circle pipeline is mainly composed of “jobs” and “workflows”, the “jobs” are pipeline main step like a compilation, a test run, a deployment while the workflows define the sequence. This makes the configuration easy to understand and well-structured.

Tasks offer a wide variety of configurations (checkout, restore_cache, run, store_test, persist, …). A very interesting command “persist_to_workspace” allows to temporarily store files through the tasks. This kind of command is often forgotten in the tools of CI/CD preferring to store the files in the repositories.

“Workflows” offer a great possibility of sequences with trigger types, filters and required.

Set up a CircleCI project

The configuration of a CircleCI project is very fast if your source code is in GitHub or BitBucket. First, sign in with your GitHub or BitBucket account.

Add a new project CircleCI. Automatically discovers your projects in GitHub or BitBucket.

Select the project to set up (“follow”) in CircleCI. If your project already has a .circleci/config.yml file then the pipeline will run immediately and offer a pipeline summary.

Management of environment variables

In order to deploy the application in AWS, it is necessary to add the configuration identifications to AWS in the project environment variables. In the “Builds” tab click on the “settings” icon of the project. In the “Environment Variables” section, add the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY keys with your AWS configurations.

These variables are now available as environment variable in all project tasks, easy!

Now that the project is set up, let’s go to the pipeline creation stage!

Pipeline-as-code: let’s get started

CircleCI uses pipelines in declarative form as opposed to scripting pipelines (see Jenkinsfile). The configuration format provided by CircleCI is quite simple to understand and many examples are available which makes it easy to create.

In the project sources, open the .circleci/config.yml script and study the content:


Version: 2
#
# Jobs are a collection of Steps. All of the steps in the job are executed in a single unit which consumes a CircleCI container from your plan while it’s running.
# Job: "maven-build" job test and package demo application with Maven, persist JAR in workspace and store it as Artefacts
# Job: "aws-deploy" job get binary from attached workspace and deploy to AWS
# https://circleci.com/docs/2.0/jobs-steps/
#
jobs:
  # Job to Build Maven application
  maven-build:
    
    # specify the version you desire here
    docker:
      - image: maven
      
    working_directory: ~/repo

    environment:
      # Customize the JVM maximum heap limit
      MAVEN_OPTS: -Xmx3200m
      
    steps:

      - checkout

      # Download and cache dependencies
      - restore_cache:
          key: demo-{{ checksum "pom.xml" }}
      
      - run: mvn dependency:go-offline
      
      - save_cache:
          paths:
            - ~/.m2
          key: demo-{{ checksum "pom.xml" }}
          
      # Run maven commands
      - run: mvn package
      
      # Store tests to compare builds      
      - store_test_results:
          path: target/surefire-reports
      # Store artifacts on CircleCI internal repository
      - store_artifacts:
          path: target/demo-1.0.jar
          
      # Persist the specified paths target/demo-1.0.jar) into the workspace for use in aws-deploy job. 
      - persist_to_workspace:
          # Must be an absolute path, or relative path from working_directory. This is a directory on the container which is taken to be the root directory of the workspace.
          root: ~/repo/target
          # Must be relative path from root
          paths:
            - demo-1.0.jar

  # Job to Deploy spring-boot demo application to AWS BeanStalk
  aws-deploy:
    working_directory: ~/app
    docker:
      - image: chriscamicas/awscli-awsebcli
    steps:
      - attach_workspace:
          # Must be absolute path or relative path from working_directory
          at: ~/app/target

      - run:
          name: Deploying
          command: |
            echo "$AWS_ACCESS_KEY_ID"
            eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"
            eb create circleci-env --single || true
            eb setenv SERVER_PORT=5000
            eb deploy circleci-env
            eb status
#
# Workflows: A workflow is a set of rules for defining a collection of jobs and their run order.
# In this demo, "aws-deploy" jobs is triggered only after the success of "maven-build" jobs
# see https://circleci.com/docs/2.0/workflows/
#
workflows:
  version: 2
  workflow:
    jobs:
      - maven-build
      - aws-deploy:
          requires:
            - maven-build

As soon as the config.yml file is added to the project, the “Builds” tab updates and provides a summary of the builds in progress and the status. The “Workflows” view is useful for seeing the progress of the pipeline steps.

Conclusion

CircleCI is hosted in SAAS mode for easy maintenance and integration with GitHub or BitBucket.

Structured configuration and simple to understand and configure sequences.

A lot of integration directly with known tools like Slack, JIRA or AWS.

CircleCI does not offer an “On Premise” version that can restrict integration into internal business infrastructures.

The cost of subscription can be expensive by adding containers or parallelism to run the pipelines.

Suivez-nous et partagez

Blogue

Continuous Deployment with Pipeline as Code – #4 CircleCI