Introduction to CI/CD: GitHub Actions

What does CI/CD mean?

CI/CD is a term describing the process of actions that occur (usually automatically) after new code has been added to a project. It can include running a suite of automated tests, building the package, compiling the code, distributing the result, compiling the documentation and more. It can mean all those things and none of them. The term has evolved significantly to mean many different things to many people.

To some it's continuous integration only, and others it's all about continuous deployment. Read on to find out what those terms mean! Some consider the automated build process to be "CI/CD" , even if said process doesn't contain any continuous integration. It is a concept that many adhere to and believe, but has become shorthand for all sorts of practices that might not technically fit the original definition. So, let's rephrase.

What is "CI/CD"?

If we define it based on CI/CD's most widely accepted definition, it is as follows. Individually there are 3 different concepts at play here alongside the term itself "see-eye-see-dee" and each has a slightly different meaning.

• CI - Continuous Integration
• CD -
  
  • Continuous Delivery
  • Continuous Deployment

Luckily, though, they are related and actually build on each other.

In order to demonstrate these meanings I am going to utilise an analogy that I worked out one lunch break to do with bicycles. Now, I'm not a bike engineer so this might get some bike-specific things wrong but please bear with me, it is a really good analogy.

CI/CD is a lot like the Bicycle Industry

Suppose you are an engineer who builds bike parts for a specific bike. Maybe you're part of a team and each of you makes different bits of the bike. You handle the chain and gears, Angelo handles the frame and materials, Chiaki works on the brakes and wheels, and Sabina is the team lead/product manager. What does a bike version release look like? Well, Sabina decides on a set of features the bike is going to have and gives out tasks to you all. Then you go away and make the various bits and the final bike is assembled after some weeks of graft. At which point the QA tester (Siobhan) shows up to put the bike through its paces and find anything that needs changing. She makes some suggestions, like "the saddle is incredibly uncomfortable" or "we're selling this bike in the Greek market so you need to translate everything into Greek" and you go away and make the changes and bring back another bike. The bike is iterated on several times and eventually a release candidate bike is produced. Siobhan signs off on it and maybe marketing have a look at it to make sure it isn't actually super offensive in the UK or something and bam it's on shelves.

Does that process sound familiar? It's probably because it is. It's an overly simplified version of the software release cycle. But without CI/CD incorporated (yet). So, now that we've got the analogy together let's have a look at introducing the first concept: CI or "Continuous Integration".

CI - Continuous Integration

Version control is at the core of what CI is. CI is the continuous integration of changes into the codebase (get it?). However, any changes must be tested thoroughly before they can be imported directly into the product. CI also includes automatically testing any proposed changes to the codebase before allowing something to be added. So let's expand the analogy.

One day your company introduces a new robot/machine to you. This machine is capable of doing all the automatable tests Siobhan would do. For example, it checks the bike wheels turn, the brakes stop the wheels when used etc. It does all the repeatable, easily defined, tests. But not just this. Whenever you finish work on a new part for the bike, you give it to the machine and log the changes you made. The robot takes your thing (new chain, say) and puts it on the current bike. Then it automatically runs all the automated tests. Maybe it finds out that your chain comes off when the bike is pedalled in reverse. So, you go away and fix the mistake, then return the chain to the robot, make a log what you changed (again) and away it goes to do the same round of tests all over again. maybe you even add some additional tests for it to carry out relating specifically to this new chain. Once the robot is happy you move onto the next bit.

"This just sounds like having a mechanical version of Siobhan!" I hear you cry, and well kind of yes, except actually no. Because, unlike Siobhan this robot is available to all the other team members all the time. The tests can all be run on every part that is added, as they are made! This is the essence of continuous integration. Every time anyone adds something, it is implemented and tested in the context of the product automatically by a fleet of robots.

Continuous Delivery is a small step further.

CD - Continuous Delivery

Continuous Delivery uses CI as its basis. Then it says "what if every time all the tests pass, we also package everything up and produce something we could release if we wanted to?". In the case of our bike analogy imagine we also had our testing robot go away and package the bike up for sale every time. Maybe this means taking it apart and flat-packing it. Maybe it means giving it a fresh oiling and putting it in a big padded box along with the manual. Maybe it means both of these things! Continuous Delivery means that whenever the team lead wants to release a new bike it's all ready to go on a moment's notice.

CD - Continuous Deployment

Continuous Deployment takes all of this one step further beyond. Now we also add continuous deployment to the mix. This means that whenever management wants to do a new release they just add a version number on the release candidate (as in Continuous Delivery) except this time the machine deploys the bike to customers who have already bought it. The machine takes your newly released bike and goes to each bike owner, quietly swapping out all the old models for the new model. Customers find their bike always has an oiled chain and working brakepads as a consequence.

CI/CD & The Sum of Its Parts

But also "CI/CD" can mean just one, or even all, of these things. Most notably people tend to say "See-Eye-See-Dee" and don't specify if they mean "delivery" or "deployment". The abbreviation has become a shorthand for anything and everything involved in the automated build process. Although, it is commonly used to refer to the glue between the processes: the bits of software that run everything to do with the automated build process. Something has to automatically spin up a virtual machine, install the software onto it, run the tests and report any failures. When software developers talk about "doing CI/CD" they really mean they're going to be developing the commands that are part of the build process.

Mapping "The Analogy" onto software

Hopefully it is now quite clear that in the bike analogy the machine/robot is the CI/CD, or "CI/CD pipeline" as it is also commonly known. If someone asks "what sort of CI/CD does your project have?", they're expecting an answer explaining the different bits of automation software you use. For example, "the code is stored in GitHub, we use GitHub Actions to build & deploy our tool". Once you've provided this context more detailed questions may be forthcoming but THAT'S what people are looking for.

CI/CD in Open Source Software

In open source software, things are a little different to the commercial world. Development is done transparently by volunteers (usually --- it depends on the company), but the key difference that I've discussed in previous articles is the lack of dedicated QA engineers, which I've mentioned in other articles. In other words, in many open source projects there is no Siobhan and there is only the robot. A consequence of this is that the automated build process is leveraged to do as much as it possibly can. Additionally, unlike commercial software, open source software is often distributed by third parties like pypi, which makes continuous deployment achievable as you are not locked into biennial release cycles. Another difference is that open source software tends to use more open and public repository stores, like GitHub, over private ones like Azure DevOps (ADO). They are also not-for profit much of the time and so need to use cheap (or free) CI/CD tools. GitHub has a built-in CI/CD tool: GitHub Actions.

Introducing: GitHub Actions

GitHub Actions (GHA) is the in-house GitHub version of the bike robot. It provides a system that can be used to test, build, and deploy software. And it does all this using YAML (YAML Ain't Markup Language™) files. YAML files are a type of text file with specific rules about how you enter data, like JSON and XML, which you might be more familiar with if you haven't heard of YAML. Or more accurately, you give it all the instructions for what to do via YAML files. All you need to do to get GitHub Actions up and running is create a new YAML file with the correct format in the correct directory and commit it to your repo. GHA will take it from there.

For full guides/tutorials on how to get up and running with GitHub Actions I recommend checking out the following resources, which are comprehensive and well thought-out.

1. https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
2. https://www.youtube.com/watch?v=R8_veQiYBjI
3. https://lab.github.com/githubtraining/github-actions:-hello-world

And one of the best things you can do is just create a dummy repository on your own personal GitHub account and add some GitHub Actions. Try it out for yourself! GHA is mostly free after all, and whilst it is not entirely free (technically you get diminished features and limited build time per month on the free version) you still get enough to trial it out without being hit with an exorbitant bill. It's ~2000 free minutes per month, at time of writing; see here for details. If you're working in the Ansys or PyAnsys organisations within GitHub, either as Ansys Employees, or otherwise, then the rules will be different as we pay for these. The repo owner has to pay for the additional minutes, even if you are not a member of the org. If you have questions about this I suggest contacting the admins of those groups.

If you're interested in setting up GitHub actions for a future project you can get a lot of the files you need through the PyAnsys Template project. If you want to start a new project with working CI/CD all you need to do is use this tool and it will set up the yaml files as needed for your GHA pipeline! It even provides the option to create yaml files that work with the ADO pipeline. If you already have a project on GitHub or ADO and want to add a CI/CD pipeline then you can also just head over to these repositories and copy the yaml files from there into your own. They are both MIT-licensed, which is very permissive.

GitHub Actions FAQ

The TL;DR of this article amounts to: "CI/CD can be done with GitHub Actions on GitHub. To add it to future projects please use one of the tools we've built for this purpose and you can easily find guides covering GitHub Actions on the internet to understand what they do." But I include some Ansys-specific FAQs that may be of use to you all to finish.

Q. What does GitHub Actions run the tests and builds on?

A. GitHub Actions spins up Linux (Ubuntu) machines which the builds and tests are run on. This is done in the cloud. It is possible to integrate the spinning up of other VMs (including our own) with GitHub Actions but I am not sure how to do this. Contact the admins of repositories that have done this if you want to know more (e.g. PyMAPDL or PyAEDT).

Q. How do I do ADO CI/CD?

A. See here.

Q. Can I use different pipelines with different repositories? E.g. ADO pipeline with a GitHub repo.

A. Yes, You can. See here, but I would recommend discussing why you might want to do this with your team first. Plus, whilst some combinations are possible, not all of them are, so I recommend researching this a little if it's a route you want to explore.