Why I Decided to Ditch my existing CI Server and Move to GitHub Actions

Preparing a to-do list for Deployment

Okay, I am gonna start with a short story before I jump into sharing a pretty solid info about my so far Journey with GitHub actions from the time its the feature is launched, originally I am writing this story now because I am currently in a discussion with one of my team about implementing GitHub actions and how we can leverage the benefits of in-house DevOps tool of GitHub family which is a recent addition, even though its just 7–8 months old baby instead of still sticking around with an yet another tool like Jenkins or Travis.

One of my team member who is fresher out from a Harvard once asked me , can you tell me some candid reasons why we should have a DevOps ? so I shared him some of my personal benefits which I aligned to my organization and customer needs while designing the Deployment process. Before explaining about the DevOps complete process instead of giving the trade-offs, I thought to breakdown into the process we derive DevOps in whole, so I started explaining about CI/CD process.

Continuous Integration (CI) is a development process where team members are integrating their work frequently, often multiple times a day. Continuous Integration also requires some level of testing, preferably automated testing, to verify build process success.

For decision makers, it is common — and natural — to follow a “Why fix it if it’s not broken?” philosophy. The idea of a workflow overhaul might sound time intensive and resource expensive, with minimal benefit to the end result.

For developers, it is difficult to ignore the areas of development workflow that could be streamlined or optimized to

(1) improve efficiency and/or (2) reduce the risk of error.

When you’re in the weeds each day, these opportunities can be incredibly apparent. So, how can stakeholders meet in the middle to ultimately deliver better web projects, faster? How can you broach the subject of Continuous Integration in a way that makes real business sense for your boss?

Business Benefits of CI/CD

All the tough days are gone when companies deployed software in annual, quarterly, or even monthly releases. Moving over to DevOps practices, software is deployed weekly, daily, or even multiple times a day without disturbing the user journey.

With DevOps, the software life cycle has been shortened considerably by incorporating automation in the end-to-end process of the delivery pipeline. It is essential to note that collaboration and communication are key, as businesses will not be able to accelerate by depending on an out-of-date software deployment process.

How DevOps Automation Help Improve Code Quality
Though the writing of code still requires human intervention, the building and deployment of applications can be automated. As building an app is a time-consuming process, using tools to expedite the process is the key.

Automated pipelines reduce manual intervention and lead to eventual savings since resources are more expensive than tools. The upfront investment can cause concern in inexperienced leadership; however, well-designed automated pipelines enable organizations to innovate better and faster to meet their customers’ needs.

DevOps Automation is broadly divided into — Continuous Integration, Continuous Delivery, (CI/CD) and Continuous Deployment.

Lets take a long breathe and understand what is CI/CD , and I still can see in my technical panel interviews even a 10 yrs experience developers struggle to give me a proper definition of it or explain it who worked on DevOps for years.

Continuous integration (CI) attempts to increase the quality of the code by testing, reviewing, and running test cases automatically. This is carried out at regular intervals each day, all with the purpose of detecting integration bugs. This facilitates a more collaborative approach when enhancing code quality and provides failure and success reports of the code in real time as well.

Continuous Delivery (CD) aims at minimizing the visibly weak areas during the deployment or release processes. Here, the implementation entails automating the steps for software deployments so that a code can be released securely and at any time.

Business Benefits of CI/CD
The CI/CD approach largely offers the following benefits to businesses:

Productive and Efficient Developers

CI aims at refining the integration process, thus breaking it down into simple, daily development tasks, to help minimize the build costs and detect defects early in the software life-cycle.

In a nutshell, by adopting the CI/CD approach, any business stands to gain the following:

  • Detect issues in software builds faster and, therefore, facilitating quicker resolutions.
  • End-user involvement and feedback during continuous development can lead to usability improvements.
  • Deliver software on time with faster time to market.
  • Showcase your capability in the market, as you adopt the best approaches (CI/CD) for producing quality mobile apps.
  • Forgo the stale periods in the lives of products.
  • Back-to-back releases using CD are easy and less time-consuming
    Share visibility of the development process in real-time.

Time-to-Market

By deploying the app to the market in time, this would not only engage customers better, but would also assure profits, support pricing, and advance market goals as well. Therefore, focusing on time-to-market would not only make you well equipped to adapt to the changes in the market but would scale up your mobile app too, which would positively affect your ROI!.

Risk Mitigation

Chances are we’ve all been involved in a “it worked on my local machine” scenario. Since local development environments often differ from where the website will actually run on the internet, there can be a number of things that are different between your local environment and where you push to production. Continuous Integration allows you to mitigate risk not only with testing, but also by enabling production parity.

Quality Assurance (QA) tasks — such as browser testing — can also be automated, mitigating the risk of a bug making it all the way through to the live site.

GitHub Actions

Now let me get back to the main agenda of this story which is GitHub Actions, so what GitHub actions brings to the table comparing to it’s other strong competitors who are in market for long time.

Why I care about Github Actions?
Before we get into the technical detail let’s discuss why developers should care about Github Actions in the first place and which benefits they provide.

Build into Github
Github Actions is fully integrated into Github and therefore doesn’t require and external site. This means that it can be managed in the same place as all your other repository related features like pull requests and issues.

Multi-container testing
Actions allow you to test multi-container setups by adding support for Docker and docker-compose files to your workflow.

Multiple CI templates
Github provides multiple templates for all kinds of CI (Continuous Integration) configurations which make it extremely easy to get started. You can also create your own templates which you can then publish as an Action on the Github Marketplace.

Great free plan
Actions are completely free for every open-source repository and include 2000 free build minutes per month for all your private repositories which is comparable with most CI/CD free plans. If that is not enough for your needs you can pick another plan or go the self-hosted route.

As a research, I decided to migrate an open-source project to GitHub Actions. This allowed me to replicate a reasonably complex test and build pipeline on GitHub’s new service, and that had revealed a lot of reasons to love and admire it.

At the heart of GitHub Actions is the idea of composing your build environment from Docker containers. At a high level, your workflow is a series of jobs, and each job can either be a script run directly on the underlying virtual machine or execute a Docker container that shares the virtual machine’s file system through a volume mount.

Composing your build environment in this way is brilliant because every major development tool already has a supported Docker container ready to use, and you are forced to no longer maintain build agents that are works of art (which is to say, build agents that have been manually tweaked and maintained over the years). There is some overhead to getting the workflow jobs just right, but this effort pays off multiple times over in the long run. It also means incremental changes to the build process can be tested in a branch without spinning up custom build agents, which is increasingly important when you consider that even dinosaurs like Java and .NET now have major releases every six months.

Having GitHub host the execution environment now means that forks also inherit the build environments. This is a huge win for open source project maintainers, who no longer have to consume code changes in order to run complex regression tests in their own build environments, and contributors can be confident their changes will pass any required tests.

Here is my quick comparison study between GitHub Actions and Jenkins

Setup GitHub Actions Workflow repo

Access the repo which you want to enable GitHub Actions which is available GitHub user account.
Navigate to the .github directory in the GitHub web interface Code tab. Click on the Actions tab and enable GitHub Actions workflow in the repo.

View the workflow in your repo under .github/workflows/build.yml. but make sure you have it set up first, starting with the environment variables on lines 1–5.

1 AWS_DEFAULT_REGION: us-east-1
2 AWS_DEFAULT_OUTPUT: json
3 AWS_ACCOUNT_ID: ${{ secrets.AWS_ACCOUNT_ID }}
4 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
5 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Ensure that line 1 has the region where your EKS cluster resides. This should match the region in your ~/.aws/config or the region specified on the eksctl command line.

Configure secrets

Lines 3–5 in the build.yml file refer to secrets. Secrets are set up in the Settings tab, which are found at the bottom of the left navigation menu in the Secrets section.

Create three secrets called AWS_ACCOUNT_ID, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY with your AWS account ID (obtainable from the AWS console or by running aws sts get-caller-identity)and the new user’s key ID and the secret key (found in your ~/.aws/credentials file). Secrets associated with your GitHub repo allow you to keep sensitive data out of your source code, but still make them available to GitHub Actions workflows.

App development workflow

Now is a good time to take a look around the repo. The containerized web app we’re going to deploy is in the app directory, whereas the Kubernetes YAML files for the Deployment and Service are in the manifests directory. The development workflow that we’re going to employ is as follows:

. Developers push changes to the app directory.

. GitHub Actions then builds and pushes container images to Elastic Container Repository (ECR), as specified by a workflow, .github/workflows/build.yml.

. Flux (automated) notices a new image in ECR and deploys it to EKS by modifying the deployment manifest, and memorializing that change with a

. git commit back to manifests/deployment.yml.

. Repo name will match up with the name used for the image repo:tag when we build it with the GitHub Actions workflow.

Now we’re going to get GitHub Actions to push our first container image there!

Finally Commit a change and copy the image URI

Once you commit the change, switch over to the Actions tab to view the running workflow:

Now click on the workflow to view the steps

Now expand the Build and tag the image step, to view most of the new image repo and the tag on the last line.

So this had enabled my life easier for seamless CI/CD setup even though its too early for GitHub actions to be in the perfect race but still I think you all should atleast try with small projects and then expand it further.

About self-hosted runners

Self-hosted runners offer more control of hardware, operating system, and software tools than GitHub-hosted runners provide. With self-hosted runners, you can choose to create a custom hardware configuration with more processing power or memory to run larger jobs, install software available on your local network, and choose an operating system not offered by GitHub-hosted runners. Self-hosted runners can be physical, virtual, in a container, on-premises, or in a cloud.

You can add self-hosted runners at various levels in the management hierarchy:

Repository-level runners are dedicated to a single repository.
Organization-level runners can process jobs for multiple repositories in an organization.
Enterprise-level runners can be assigned to multiple organizations in an enterprise account.

Your runner machine connects to GitHub using the GitHub Actions self-hosted runner application. The GitHub Actions runner application is open source.

You can contribute and file issues in the runner repository. When a new version is released, the runner application automatically updates itself when a job is assigned to the runner, or within a week of release if the runner hasn’t been assigned any jobs.

A self-hosted runner is automatically removed from GitHub if it has not connected to GitHub Actions for more than 30 days.

Differences between GitHub-hosted and self-hosted runners
GitHub-hosted runners offer a quicker, simpler way to run your workflows, while self-hosted runners are a highly configurable way to run workflows in your own custom environment.

GitHub-hosted runners:

Receive automatic updates for the operating system, preinstalled packages and tools, and the self-hosted runner application.
Are managed and maintained by GitHub.
Provide a clean instance for every job execution.
Use free minutes on your GitHub plan, with per-minute rates applied after surpassing the free minutes.

Self-hosted runners:

Receive automatic updates for the self-hosted runner application only. You are responsible updating the operating system and all other software.
Can use cloud services or local machines that you already pay for.
Are customizable to your hardware, operating system, software, and security requirements.
Don’t need to have a clean instance for every job execution.
Are free to use with GitHub Actions, but you are responsible for the cost of maintaining your runner machines.

The below official GitHub Actions

will help further to understand better and I would say…welcome a new comer…it may be your best trump card to be more productive especially during this new normal.

https://docs.github.com/en/actions

Enterprise Architect — Certified Cloud Specialist (Azure, Google, AWS and Alibaba), AI/AR SME, Cross Platform Mobile Development (React Native, Xamarin, iOS)