CI + QA

Continuous Integration (CI) and Quality Assurance (QA) are fundamental pillars in our development lifecycle. We aim to automate as much as possible to deliver high-quality software quickly and consistently.

Continuous Integration (CI) Pipeline

We use GitLab CI/CD as our CI platform. Every GitLab project must include a .gitlab-ci.yml file that defines the pipeline. A typical pipeline includes the following stages:

1. Build:

   • The source code is compiled.
   • Required artifacts are built (for example, a JAR file for a Java application).
   • The application's Docker image is built.

2. Test:

   • Unit Tests: Unit tests are run to verify the behavior of individual components. We target code coverage above 80%.
   • Integration Tests: Tests are run to verify interactions between different system components.

3. Code Quality & Security:

   • Static Application Security Testing (SAST): We use tools such as SonarQube to analyze code for bugs, vulnerabilities, and code smells. The pipeline fails if defined quality thresholds are not met.
   • Dependency Analysis: We scan project dependencies for known vulnerabilities using tools such as OWASP Dependency-Check or Snyk.

4. Push to Registry:

   • If all previous stages succeed, the Docker image is tagged and pushed to Google Artifact Registry.

Branching Strategy

We follow a GitFlow-based strategy, simplified as follows:

• master: Contains stable code that is deployed to the integration environment (UAT) for validation, and then to production. Merges only from develop through Merge Requests.
• develop: The main development branch. It contains the latest features ready for testing.
• feature/<feature-name>: Each new feature is developed on its own branch from develop. Once complete, a Merge Request is created to merge it back into develop.

Merge Requests must be reviewed and approved by at least one other team member before being merged. This ensures code quality and shared knowledge.