How do we do CI/CD?

If you’ve read the article about the benefits of CI/CD, you may have been motivated to deploy these practices on your project too, and now you’re wondering how to get started. In short, to put CI/CD theory into practice, you need to design a system to deploy new code into production. This system is called a pipeline and consists of jobs that are performed automatically. How do we set it up at Crossuite?

Currently, we use two tools for CI/CD, namely GitLab and Jenkins. We’re using GitLab more intensively and we’d like to eliminate Jenkins altogether, because it’s difficult to integrate with Gitlab and it provides insufficient feedback for developers. 

My colleague Šafo wrote an article about how to set up automated deployments via GitLab, so if you use it, you’ll find a great tutorial there.

The process itself is divided into two pipelines, each with several jobs that can end in failed/successful states.

The merging pipeline includes:

1. Code Formatting – Each new code is formatted according to the project’s set standards. As a result, fewer unnecessary conflicts arise in the merge and the code reads better overall. 
2. Linting – ESLint performs static code analysis, again according to the best practices and standards set for the project. The program runs through the entire code and notifies you of unused variables, non-executed codes, and so on. Any discrepancies are then divided into warnings and errors. Notifications are just friendly recommendations for editing, but errors simply don’t pass through the job and the programmer has to fix them.
3. Build – This build is for testing and includes:
   1. Minification/Uglification of code – To simply make the project smaller.
   2. Transpilation of typescript into javascript – So that each browser can deal with the functionality.
   3. Splitting into chunks – So that we can dynamically load javascript while the application is running.
4. Testing – At this point, we launch a series of simple automated tests
   1. Unit tests – They only test individual functions or small pieces of code without external dependencies.
   2. Integration tests – They check how components within one system (API, FE, microservice) communicate with each other.
   3. Bonus: End-to-end tests – In the case of important merges, we also run more demanding end-to-end tests that will automatically click through to the project.

If the entire pipeline lights up green, and we therefore have success, the code will successfully merge and pipeline 2: deployment, is triggered. It contains everything that the migration pipeline does, plus some little things. If this pipeline is also successful, the update will be deployed “live”.

But what if we don’t want to show users what we’re deploying yet? Hide it under the feature flags! We’ll write about them next time. ?