By Sébastien Bernard, Solutions Architect | Expert in Code Quality, DevOps, and Generative AI Integration | Passionate about Innovation and Customer Success.
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 a 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, fueling 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
GitHub Actions
Goal
The seventh competitor is GitHub Actions, the CI/CD native tool embedded in the famous GitHub Platform. GitHub Actions stands out for its deep integration with GitHub, offering developers an intuitive and seamless CI/CD experience.
You will find the other articles by clicking here: #1-Jenkins, #2-Concourse, #3-GitLab, #4-CircleCI, #5-TravisCI, #6-Azure DevOps
GitHub Actions is GitHub’s platform for continuous integration and continuous delivery (CI/CD) that replaces the need for external CI/CD services. Since its launch in 2018, GitHub Actions has become a favorite among developers for its flexibility and extensive ecosystem. GitHub Actions provides a robust, integrated environment that supports all aspects of the development lifecycle: source code management, continuous integration, deployment, and monitoring.
Key features:
Marketplace Integration: Similar to Azure DevOps, GitHub Actions offers a marketplace where developers can find pre-built actions created by the community. These actions can be included in workflows to perform common tasks, such as setting up a particular environment, running tests, or deploying to cloud platforms. The marketplace hosts thousands of actions, ranging from simple utility functions to complex deployment scripts, allowing developers to build sophisticated workflows with minimal effort.
Reusable Workflows: GitHub Actions allows for the reuse of workflows within the same organization. This feature enables teams to create standardized workflows that can be referenced across multiple repositories, ensuring consistency and reducing duplication of effort. This is particularly useful for organizations with multiple projects that require similar CI/CD processes. By defining reusable workflows, organizations can maintain best practices and streamline their development processes.
Integration with GitHub Repositories: GitHub Actions integrates seamlessly with GitHub repositories, providing native support for GitHub events like pushes, pull requests, and issue creation. This deep integration ensures that workflows are tightly coupled with the repository’s activity, enhancing automation and efficiency. For example, you can trigger a CI build automatically when a pull request is opened, ensuring that code quality checks are performed before any code is merged.
Matrix Strategy: GitHub Actions supports matrix builds, allowing you to run jobs with multiple configurations simultaneously. This feature is particularly useful for testing your code across different environments, such as various versions of a language or dependency. By specifying a matrix of configurations, you can ensure that your code works in all targeted environments. This can save significant time and effort in testing, as it allows for parallel execution of tests, making it easier to identify compatibility issues early in the development process.
Structure
GitHub Actions provides two main ways to create and edit workflows: using the GitHub web interface or directly editing the YAML files in the repository. A workflow contains jobs that can be run in parallel, and each job consists of multiple steps. These steps can include actions like checking out code, setting up dependencies, running tests, and deploying applications.
Now that we understand the platform better, let’s dive into the configuration of our repository!
Configure your repository for GitHub Actions
First, you need to create a repository on GitHub. GitHub Actions are free for open-source projects, making it a great choice for automation. For this tutorial, we will create a public repository. A public repository allows others to view your code, which can be beneficial for collaborative projects and open-source contributions.
Once the repository is created, navigate to the settings of the project. Here, you need to activate all actions and reusable workflows for the project. This step ensures that GitHub Actions can run without any restrictions, providing the necessary permissions for the workflows to execute correctly.
Next, we need to configure the secrets required to access the AWS instance. Secrets are crucial for securely storing sensitive information such as access keys. In the settings, go to the “Secrets and variables” menu and add the necessary secrets. For this tutorial, we will add `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_REGION`. These secrets allow your GitHub Actions to authenticate and interact with AWS services securely.
With the repository and secrets configured, you’re now ready to deploy your first GitHub Actions! This setup streamlines the deployment process, making it efficient and secure.
Add your first workflow
To create your first action for the project, navigate to the “Actions” tab in your repository. Select the *set up a workflow yourself* option. This allows you to create a custom workflow tailored to your project’s needs.
Rename the workflow file to `build-deploy.yml` and insert the following code:
name: Build and deploy
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
name: Build package
runs-on: ubuntu-latest
steps:
– name: Checkout code
uses: actions/checkout@v3
– name: Set up JDK 1.8
uses: actions/setup-java@v3
with:
distribution: ‘temurin’
java-version: ‘8’
– name: Build with Maven
run: mvn package –file pom.xml -Dmaven.repo.local=.m2
– name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: continuous-deployment-demo
path: target/demo-1.0.jar
deploy:
name: Deploy to AWS Elastic Beanstalk
runs-on: ubuntu-latest
steps:
– name: Download Artifact
uses: actions/download-artifact@v4
with:
name: continuous-deployment-demo
– name: Deploy to EB
uses: einaregilsson/beanstalk-deploy@v22
with:
aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
application_name: continuous-deployment-demo
environment_name: github-env
version_label: 1.0
region: ${{ secrets.AWS_REGION }}
deployment_package: target/demo-1.0.jar
This YAML file defines a workflow named “Build and deploy” that triggers on push and pull request events to the `master` branch. It consists of two jobs: `build` and `deploy`.
- The `build` job checks out the code, sets up JDK 1.8, builds the project using Maven, and uploads the artifact.
- The `deploy` job downloads the artifact and deploys it to AWS Elastic Beanstalk.
This setup ensures that every push or pull request to the `master` branch results in a new build and deployment, maintaining continuous integration and delivery.
The final workflow file should look like this:
Commit your changes, and you have successfully added your first GitHub workflow to your repository! This workflow will automate your build and deployment process, saving time and reducing the potential for human error.
Conclusion
The deep integration with GitHub features allows developers to create actions with access to multiple unique capabilities, such as seamless interactions with GitHub APIs, automated code reviews, and deployment workflows
It allows for easy reuse of workflows across the same organization and through the marketplace, promoting consistency and reducing duplication of effort.
The matrix strategy feature enables parallel testing across multiple environments, improving testing coverage and reliability.
While GitHub Actions supports self-hosted runners, the default GitHub-hosted runners may have limitations in terms of customization and resource allocation.
GitHub Actions lacks some advanced features that might be required by large organizations, such as detailed analytics, insights, and manual approvals
Get Expert DevOps Advice
Do you want to create your automated software deployment pipeline and accelerate your deliveries? Gologic’s DevOps advisors can help you set up pipelines as code, including continuous development, integration, testing, delivery, and deployment (CI/CD). Explore our services or contact us to learn more about our strategic approach.
