Automating things

Surely if you are more or less new to the world of programming you will have heard one or two things about "CI/CD"  or heard the word "Jenkins" being mentioned.

If you don't know what those words mean... this is the post for you! I will try to explain everything you need to know about CI/CD in case you want to take your first steps (if you are a veteran you are also welcome).

What is CI/CD?

This is a code distribution methodology that covers the entire code life cycle. From the time new code is developed and integrated into the existing code, until a version of the application is deployed or distributed with the new code, along with subsequent version monitoring  to check for possible bugs.

When we refer to CI/CD we are referring to two different terms or work philosophies based on the automation of tasks, which are:

CI → Continuous Integration

CD → Continuous Delivery/Deployment

Let's look at these two concepts separately.

Continuous Integration, a.k.a. "CI".

It is very common that in your work environment you do not work alone but you work together with other team members and each of you work on completely different parts of the project. This is most common, and what is even more common is the "merge day", that wonderful day when all the code is brought together to work in harmony.

But... oh boy! Something went wrong. Too many changes in the project, everyone is in pain and what seemed to be a wonderful day, turns into a gray day of regrets and disappointments.

Continuous integration to the rescue

Continuous integration (CI) consists of a work philosophy based on integrating the code written by a developer into the main project as soon as possible (it is no good uploading code with bugs, we already know that...).

In this way, this code is made accessible to the rest of the teammates, in some cases on the same day.

To avoid possible errors in the integration, it is necessary to have different tools such as :

• Unit Tests
• Integration Test
• Code analysis
• Code review, etc...

It is not necessary to incorporate all these tools to your project. They can be incorporated progressively depending on the needs you want to cover or the size of the project. If it is a small project, you may not need to add a code analyzer, such as SonarCloud, SonarQube, DeepSource, etc...

Continuous Delivery VS Continuous Deployment

Sometimes we could make the mistake of not knowing how to differentiate between continuous delivery and continuous deployment. At first glance, both concepts seem very similar since the final objective is the same, to release a version.

The difference lies in who performs the action, i.e., whether it is the developer or a third party who performs the action of deploying the version (either by pressing a button in Slack, launching a command in the terminal or simply sending a version for review), we are talking about continuous delivery.

On the other hand, if the developer or a third party is not required to perform this action but it is executed in a fully automated way, we speak of continuous deployment.

And who controls this?

At this point, you are probably wondering what you need to do to set up your project with CI/CD and see if this works for you or not.

It is very common to think that you need a whole team of people to set up an IC/DC ecosystem for your application, to set up a big rack of machines connected to a big network with a very high connection speed and to do super complicated and complex tasks like you are entering the Matrix. And no, you're not.

The developer also set up pipelines

Normally we tend to think that this is a task that should be done by the infrastructure or SRE team in the development team, but I believe that this is not the case.

The infrastructure team should provide you with the environment to set up your workflows (virtual machine, Kubernetes, etc...), but developers should be autonomous enough to be able to set up the workflows or pipelines by themselves and make the necessary modifications.

Let's think about it more carefully... the developer is the one who best knows the requirements of the application environment, what he needs to test, how he needs to test it, how he needs to generate the versions and so on and so forth. In the same way, the infrastructure team knows much better all the security aspects of the VPN you use to work, where the hosted repository is located, etc... That is why I consider that it is the responsibility of the developer to set up the pipelines or workflows since he/she is ultimately responsible for making sure that his/her code works in the best possible way.

Okay, so what do I do if I can't maintain the IC/DC system myself?

Nowadays there are very easy to use tools that allow you to have a CI/CD ecosystem in a few minutes by editing just one file.

GitHub Actions (includes support for iOS) allows you in a few steps - and by setting up a YAML file - to create a whole ecosystem of workflows that will be executed when a pull request is opened, a tag is created, a commit is uploaded to a branch, etc...

Here’s is an example of how we can set up a simple workflow in Github Action to run some tests of our application on different versions of MacOS

# This is a basic workflow to help you get started with Actions

name: Testing

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "master" branch
  pull_request:
    branches: [ "master" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  macos:
    strategy:
      fail-fast: false
      matrix:
        macos:
          - 11
          - 12
        xcode:
          - latest-stable
        include:
          - macos: 11
            xcode: latest
    runs-on: macos-${{ matrix.macos }}
    steps:
      - name: Get Sources
        uses: actions/checkout@v2

      - name: Setup Xcode
        uses: maxim-lobanov/setup-xcode@v1.4.0
        with:
          xcode-version: "13.1"

      - name: Build Package
        run: swift build -v

      - name: Run tests
        run: swift test --enable-code-coverage -v

Apart from GitHub Actions there are many other options, such as: CircleCI, Bitrise, CodeMagic... you simply have to find the solution that best suits you and start testing!

I can only leave you with one last opinion about integrating CI/CD to your project, and here it is: