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
A 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.
