A CI Praxis — Exploring Continuous Integration Via Github Actions

As full-stack developer in-training, I have found using Github as a medium for code management to be seamless and coherent in many instances, and maddening in others. I certainly recognize its utility in working on group projects, and I appreciate all of the Git-related features that are found in VS Code, my current code editor of choice. Yet I will be the first to admit that I have accidentally merged, overwritten, and lost code numerous times, particularly when I first started using the Git ecosystem. Therefore I must also reveal that I was initially reluctant to approach the topic of continuous integration, until it became absolutely necessary for me to incorporate the practice into my developer education. However, I found the topic to be interesting, and not as daunting as I anticipated. What follows is my exploration of continuous integration and continuous delivery using Github Actions, and what developers who are new to the subject are to expect.

CI/CD/CCO/XP/Many/Other/Practices/Known/By/Short/Acronyms

Before we tackle Github Actions and its usefulness in software development, it is worth mentioning a few other concepts which fall under the same umbrella as continuous integration, that being general software engineering practices. A practice in this respect is any set of guidelines which attempt to organize and streamline the process of software development, from the initial generation of ideas, to the finished product, which would typically in our case be a working full-stack application deployed for use by the public.

The first and most common software engineering practices include paired programming, and test-driven development, which both function exactly as described in their respective names, the latter of which employing unit testing libraries such as Mocha and Chai for JavaScript, for example. More structured development practices tend to be described as models or paradigms, and include examples such as behavior-driven development, which follows the agile paradigm. Agile, a practice which emphasizes features such as self-organizing and continuous improvement, underpins many software development frameworks, including Scrum, a broad set of practices which can extend beyond software into any technology related focus.

Continuous Integration, or CI, as we will refer to it here, may incorporate many of the above practices as well as other common tasks to software engineering, but its most defining feature is that of merging all of the developers’ working copies of a shared codebase to a mainline multiple times daily through the duration of a project. The original proposal, made by software engineer Brady Booch in 1991, was called the Booch Method, and it applied specifically to object modeling languages using an object-oriented programming paradigm (OOP). This designation of course applies to some of the most widely used languages in coding, including JavaScript, C++, Java, Python, MATLAB, and countless others. The Booch Method itself did not advocate code integration several times a day; the modern formulation of CI including this approach was adopted from the Extreme Programming methodology, which, itself influenced by agile practices, emphasized frequent releases in short development cycles.

One advantage of the frequent integration approach is that decreases the chance of merge conflicts between a side branch and the main branch of a codebase. This is simply because the longer a developer maintains an autonomous branch, the greater the deviation of work, and thus without constant, or continuous, checks with the main branch, the likelihood of significant merge conflicts increases. This is the ultimate rationale of continuous integration — avoiding ‘merge hell’, or ‘integration hell’, in which the time interval spent integrating code, new libraries, and new dependencies threatens to become more consuming than the actual changes or improvements made to the codebase.

Currently, CI is often intertwined with continuous delivery/continuous deployment to form what is termed the CI/CD pipeline. ‘Continuous delivery’ makes sure the software checked in on the mainline is always in a state that can be deployed to users and “continuous deployment” automates the deployment process.

Github Actions For CI Execution

Now that some overview has been established as to software engineering practices, we may examine how to undertake a CI process. This is where Github Actions comes in. It is a service which uses the CI/CD pipeline to automate the software workflow. Since Github itself is already such a well used medium for version control and project collaboration, this is an ideal choice for CI goals.

The Github Actions environment operates under a few main areas carried out for a given Github repository. These areas are mostly hierarchical in structure, and thus can be described accordingly as follows:

• Workflow — this is the highest level procedure that is added to the repository. The workflow includes a set of processes for a Github project. These encompass the building, testing, releasing, and deployment of a project via its repository. Workflows are automated procedures, consisting of jobs, and scheduled or triggered by events.
• Event — specific activity which triggers a workflow. Activities such as pushing commits to a repository or issuing a pull request can function as events which may be tied to a given workflow.
• Job — A set of steps which operate on the same runner (see below). Jobs may run in parallel, or sequentially, as specified.
• Step — An individual task which may run commands from within a job. Steps may either be actions or shell commands, and must execute on the same runner, allowing data share between actions.
• Runner — A server, which operates on the Github Actions runner application. These may be hosted by Github or on developer’s own environment. Runners listen for jobs, and execute one at a time, reporting metadata in the process.
• Actions — The most atomized portion of the workflow, actions are the actual commands which form steps, which in turn form a job. The Github community has already created actions, but custom ones may be defined as well. Actions must be included with a step to be used in a workflow.

Analysis of A Workflow

GitHub Actions uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called .github/workflows.

You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, GitHub Actions checks out the pushed code, installs the software dependencies, and runs bats -v.

1. In your repository, create the .github/workflows/ directory to store your workflow files.
2. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.

3. Commit these changes and push them to your GitHub repository.

Your new GitHub Actions workflow file is now installed in your repository! This will run automatically each time someone pushes a change to the repository.

The following diagram shows the workflow that we just created:

The first two steps execute prebuilt actions. Once this job has started running, a visualization graph representing the run’s progress and the activity of each step is accessible on Github, by selecting ‘actions’ on the main page of the repository. You can also navigate to workflow runs from this page, as well as the results of each job. This page in Github Actions documentation conveys how you can customize actions to be produced within a workflow.

While setting up a Github Actions workflow or any CI/CD pipeline for the first time requires understanding a few core concepts along the configuration process, it can prove to be quite beneficial to a project of any size. In addition, the fact that these automation process can be started and run from within a project repository makes Github Actions an ideal choice for a CI workflow. I hope this post has been helpful in introducing some of the concepts related to software management practices, as well as setting up a workflow. Thank you for reading!