Evaluation of GitHub Actions as the potential alternative (replacement or complement) to Jenkins for Continuous Integration (CI) in our organization.
The daily mood
Beside spending time reporting on my activities, I have the opportunity to backup one of our team lead with mentoring a student for about one month. He has already worked in part-time for about 3 years in our organisation, as a Java developer. He is now looking for a short engagement within the architecture team.
We agreed on the goal to create a document that is collecting all required informations around GitHub, and eventually run a small PoC/showcase.
Git
Git is a distributed version-control system for tracking changes in source code during software development. It was crated by Linus Torvalds in 2005 for development of the Linux kernel. It is a free software under GNU license. There are Git clients available for my different OS and code editors. And like for HTTP server there are tons of hosting providers and distributions available, with the most popular being GitHub. Because it started early in 2007, and didn't only adopt a public cloud infrastructure sharing approach, but also a public cloud repository indexing and sharing. With this, GitHub gained high adoption by open-source developer communities.
Git flow
The sake of a code repository is to grow over time, not only through lines of code and history of changes, but also through the number of users and assets like for ex. branches, packages, releases etc. Unfortunately Git generally lacks on enforcing best-practices and so requires guidelines. Git flow was the first standard one consisting of a spec and wrapper tool for implementing high-level repository operations based on Vincent Driessen's branching model. In this model, the main or "developer" branch is restricted for push to a bunch of authorised people, while other developers are forced to work on their own branch.
# instal git-flow
$ apt-get install git-flow
# initialize an existing repo
$ git flow init # from here on you may work on a feature, a release or a hotfix
git flow feature start feature-yx
git flow feature finish feature-xy
git flow feature publish feature-xy
git flow feature track feature-xy
Source: git-flow cheatsheet by Daniel Kummer
Trunk-based development
Experience shows that Git Flow does not work for any kind of project. Trunk-based development is a less restrictive alternative to it that you might have to consider. This article compares the two approaches.
That part was "just" developer side...
From infrastructure to platform
It rapidly became obvious that developers could use more than just source code management (SCM). Potentially influenced by big social networking platform like Facebook, GitHub originally focused on social profiles, connections and analytics. It was nice for hobby developers but less convenient for collaboration at business level. Starting 2009, they added a wiki called Gollum, an issue tracker, a code review workflow (using pull-requests) and a lightweight alternative to Git flow called GitHub Flow. Developers started to spend more and more time on GitHub which significantly increased its value and attractivity. Microsoft bought the platform in 2018. In 2020, "all of the core GitHub features" became free for everyone, including "private repositories with unlimited collaborators".
From SCM to DevOps
Like CircleCI and Azure DevOps pipelines, GitHub Actions is a hosted feature from GitHub for supporting CI/CD. The idea behind is to provide some infrastructure to developers for building, testing and shipping their code. While you are developing, you generate valuable events in GitHub through your activities (ex. push, tag, pull-request) so that much repository automation could happen in place. In case you don't want to support Microsoft, then Git Lab CI/CD is your alternative.
How does this work
It is not a secret that GitHub is scanning your code to get value out of it. They actually get a lot of value, and give you some back, hence you get a lot for free. Recognizing your programming language from code is a typical use-case for which they use a tool called linguist. Based on that, you will appreciate some syntax highlighting/auto-complete as part of your code preview, but also a recommendation of appropriate actions for implementing what they call a workflow. In addition to a basic set of standard actions maintained by GitHub with the purpose of getting started, a dedicated Marketplace allows the community to share apps and actions. Note that apps are persistent applications deployed using actions. Workflows can be executed on a GitHub-hosted or on self-hosted runner.
Workflow
The workflow is basically a CI/CD pipeline that runs on containers or on VMs depending on the OS. It is defined as a declarative file (yaml) that looks like this
name: my-ci-pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest # or self-hosted strategy: matrix: key: [values] # you may set for ex. which engine version to use per run steps: - ... # run commands or reference actions from here # use above key-value pairs with ${{ matrix.key }}
In addition to matrix key-value pairs, the workflow also supports GitHub secrets. Secrets can be defined organization-wide or repository-wide, and can be shared with other repositories. At the end of an execution, repository users may look at report or get notified for ex. via the Slack action..
Runners
All GitHub runners are provisioned on Microsoft Azure as standard Linux, Windows or MacOS VM with the following specs:
- 2-core CPU
- 7 GB of RAM memory
- 14 GB of SSD disk space
Self-hosted runner are paired with your account using a token, then frequently pull workflow jobs:
Conclusion
We will rely on the student to collect some requirements from his past experience at R&D, define and implement some use-cases from the real world. We are already aware that there will be some interesting questions and challenges:
- flexibility in the workflow definition
- are existing actions sufficient or do we need to write and maintain our own
- access to our internal artifact repository (for package)
- access to our internal data or services (for test)
- which events to use and not use
- who is to create, use and monitor secrets or workflows
- can we migrate existing workflows from Jenkins
- triggering, execution and notification time
- quality of the report / api
- troubleshooting/loopback assistance
- what is the level of maturity on CD
Next we will have a checkpoint on a weekly basis.
Comments
Post a Comment