Continuous Deployment with Pipeline as Code – Quick start Series – #3 GitLab

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

Goals Series

This series of articles explores various tools for executing pipeline as code and deployment.

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

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

Each article is divided into several parts:

  • Installation and start-up of a CI/CD tool
  • Configuration of the CI/CD tool (if needed)
  • Code continuous deployment pipeline
  • Check deployment
  • A simple conclusion

If you want to run a pipeline, you will need:

  • Docker runtime to execute pipeline steps
  • An AWS BeanStalk environment with access key and secret to deploy 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 within 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 development infrastructure.

Pipeline as code defines the deployment pipeline through code instead of configuring a running CI/CD tool.

Source code

GitHub Demo Reference is there: Continuous Deployment Demo

GitLab

Goal

GitLab is the next target for our third article. You’ll find the first, second article by clicking here: #1-Jenkins, #2-Concourse.

GitLab is a suite of tools used to manage the complete development of an application. It integrates the entire DevOps development and delivery cycle of an application. This suite is truly impressive in its coverage, the quality of its tools and the complete integration of each feature.

This article will present the pipeline section. The GitLab pipeline function works as a YAML description. The configuration is stored in the project.

The pipeline is triggered when a source code is changed on a branch, whether it is a change in the source content or the pipeline itself. Since everything is integrated within the project and its branches, the source code checkout is implicit when running the pipeline.

A pipeline is composed of internships and tasks: internships are phases of the pipeline such as “Build” or “Deploy”. Tasks are associated with internships and are run in parallel for each internship.

Tasks are mainly script executions and invoke Dockers to execute the operations. Several elements are available in tasks to be realized. Documentation is available at this location.

Install and start GitLab CE with Docker

Start GitLab with Docker by following the official instructions: https://docs.gitlab.com/omnibus/docker/README.html

Check GitLab’s availability at: http://localhost

Then log in by changing the password and log in with the root account according to following instructions.

Creating a project

The prerequisite for using the GitLab pipeline is to create a project. A project can easily be created by following the instructions on the GitLab home page, as shown in the overview below.

Once your project has been created, you must add the source code by following the GIT instructions on the project page.

Installing a GitLab Runner

GitLab Runner allows you to perform pipeline tasks. At least one Runner is required in addition to installing GitLab. A Runner is easy to execute as indicated in the installation and registration documentation.

Once the Runner is available, it is possible to run an application’s pipeline!

Pipeline as code: let’s get started

GitLab uses pipelines in declarative form, unlike scripting pipelines (see Jenkinsfile). Mastering this format requires a substantial learning curve. GitLab’s excellent documentation is extremely helpful in beginning the learning process.

In the project sources, open the .gitlab.yml script and check the content:

# Base docker image to run pipeline
image: docker:latest
services:
  - docker:dind
  
# path to cache Maven dependencies
cache:
  paths:
    - .m2/

# Stages in pipeline
stages:
  - build
  - deploy

# Build maven step
maven-build:
  # Use maven docker image
  image: maven
  # Join to build stage
  stage: build
  # Command to execute in docker image
  script: "mvn package -Dmaven.repo.local=.m2"
  artifacts:
    paths:
      - target/*.jar

# Deploy AWS step
aws-deploy:
  # Use aws docker with eb-cli
  image: chriscamicas/awscli-awsebcli
  # Join to deploy stage
  stage: deploy
  # Commands to execute to deploy application to AWS
  script:
  - 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 gitlab-env --single || true
  - eb setenv SERVER_PORT=5000
  - eb deploy gitlab-env
  - eb status

As soon as the .gitlab.yml file is added to the project, the pipeline view becomes available via the menu, or by adding /pipelines after the project address.

List of pipeline executions

Details of a pipeline

The pipeline (.gitlab.yml) is defined. With each code change, the steps and stages are triggered to compile, store in the pipeline’s working folder, and deploy to AWS.

Thanks to its integration, changes to the source code are visible in the detailed view of the pipeline and, conversely, pipeline executions are visible in the source code change view. This integration facilitates branch status navigation and validation.

Conclusion

GitLab offers a complete suite for managing an application’s DevOps cycle.

GitLab offers complete and intuitive integration for all features.

Pipeline execution of merge-request is triggered automatically.

GitLab does not offer a CLI to test pipeline execution. One must “commit” the pipeline to see it running, which can lead to much trial and error.

Substantial learning time is required to master the declarative pipeline YAML syntax and use it without error.

Suivez-nous et partagez

Leave a Reply