In order to configure [email protected] with GitLab, there are a number of key features that need to be setup on the platform before executing the pipeline. Whether you are new to GitLab or have prior experience developing CI/CD for other software stacks on GitLab, this guide is meant to summarize the key configuration steps on the platform and use the templates provided in our sample repository.
There are a number of security considerations that need to factored into the setup of your GitLab project and pipeline. The following list will walk you through some considerations as you use the template and customize your pipelines for deployments.
- Protected Branches - Permissions are fundamentally defined around the idea of having read or write permission to the repository and branches. To impose further restrictions on certain branches, they can be protected. At a minimum, the main branch should be protected and certain releases branches created from main should be candidates for protection.
- Permission and Roles - Users have different abilities depending on the role they have in a particular group or project. Review the structure of your team and confirm who to designate as Maintainers and who are primary Developers.
- CI/CD Variable Types - Project, group and instance CI/CD variables can be Variable or File type. File type CI/CD variables are used in the template for storing sfdxurl file as input for authentication to Salesforce instances. Protect variable and Mask variable should be reviewed for each variable defined in the project to ensure that variables masked in job logs and can only run on protected branches or tags.
- Using external secrets in CI - Secrets represent sensitive information your CI job needs to complete work. This sensitive information can be items like API tokens, database credentials, or private keys. Secrets are sourced from your secrets provider.
The .gitlab-ci.yml template file is the primary configuration file used for executing continuous integration, delivery and deployment on the platform. This CI/CD configuration file exists by default in the root directory of your repository and controls pipeline execution of stages and jobs triggered from updates to the repository via merge requests/merges, scheduled executions, or manual execution of the pipeline.
Template Code Structure
The diagram below depicts the various stages and jobs configured in the GitLab CI/CD configuration file .gitlab-ci.yml which incorporates the sfpowerscripts orchestrator and sfpowerkit package commands to manage your CI/CD process. The grouping of stages and jobs are split into merge requests, merges, and manual triggers of the pipeline.
The diagram below highlights the dxatscale-template recommended scheduled jobs and manual job for Scratch Org Pool Management. The stages and jobs configured in the GitLab CI/CD configuration file .gitlab-ci.yml uses the sfpowerscripts prepare commands to build scratch org pools for Developer and CI Scratch Orgs. Additional schedule job for publishing metrics to your dashboard platform is provided as well.
Metrics should be a key part of your DevOps process. It is through these metrics, one can drive continuous improvement of your delivery process.
The following variables are required to be setup in your project variables to push the metrics to New Relic.
- SFPOWERSCRIPTS_NEWRELIC (Optional)
- SFPOWERSCRIPTS_NEWRELIC_API_KEY (Optional)
There are additional configurations for the GitLab Project that should be reviewed and configured to ensure it aligns with your internal IT policies.
- Merge requests - Merge method, merge options, merge checks, merge suggestions should be reviewed to determine preferred approaches such as merge commits, deleting source branches by default option, and allowing squash commits when merging.
- Merge request approvals **- Merge request approval rules prevent users from overriding certain settings on the project level. Define the number of approvals** required for merging into specific branches and specify users or groups that are allowed to approve them in the approval rules.
The following are additional design configurations to consider when using this template:
- 17.Automated Testing Integration
- 18.Static Code Analysis Integration
- 19.Dynamic Code Testing Integration
For GitLab SaaS hosting, Project Access Tokens are only available for Premium and above licenses and self-managed instances on Free tier and above.