Build Servers...
Scrum & Continuous Integration (CI)...
Continuous Integration (CI) is an automated process of building, testing and merging code changes to a shared repository.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
A continuous integration/continuous deployment pipeline is a series of automated steps to deliver a new version of software to users.
CI (Build) Server...
A build server, also called a continuous integration server (CI server), is a centralized, stable and reliable environment for conducting automated builds including activities like compiling source code into binary code, packaging binary code, and running automated tests (code inspection, unit & integration tests).
A continuous integration server automatically tests the code written by individual developers to make sure it can be merged into the main code base.
This minimizes the risk that a code change could cause serious problems and force developers to revert their application to an earlier state.
The importance of CI Servers...
Case scenario:
You are a full-stack web developer and you need to set up software dependencies for your project so that you can develop, build and test your web application.
This might result in several tools and utilities being installed on your computer, as well as software packages. Another developer joins your team, and that developer needs to go through the same setup process.
The new developer's computer could be of a different architecture and configuration, resulting in failed compilation and tests.
Even if your developers are working on computers with the same architecture and platform, a developer may update the OS (env variables, for example) or other tools. What works with the updates could result in failed builds for others.
A developer may use a library that is not deployed, in which case the other developer's code will not compile.
Your code does not follow good programming practices and standards, contains bugs, and does not follow agreed coding style.
Common CI/CD Servers...
GitLab CI Architecture...
In GitLab, runners are agents (SW components) that run your CI/CD jobs on separate servers. To view available runners go to Settings > CI/CD and expand Runners. By default, the executor pulls from DockerHub the Ruby docker image.
The .gitlab-ci.yml file is a YAML file where you configure specific instructions for GitLab CI/CD. In this file, you define:
- The structure and order of jobs that the runner should execute.
- The decisions the runner should make when specific conditions are encountered.
Use cache for dependencies (packages downloaded from internet). Use artifacts to pass intermediate build results between stages. Artifacts are generated by a job, stored in GitLab, and can be downloaded.