There is a useful division of labor between a CI/CD system and configuration management. GitLab CI/CD can build, test, and promote a change. SaltStack can make a machine match the state that the change describes. Keeping those jobs distinct makes both systems easier to understand.
Let the pipeline prove the change
A pipeline should answer whether a change is fit to move forward. That usually means linting, unit tests, integration tests, image builds, and whatever checks are specific to the service. It should also produce an artifact that can be identified later—not just “whatever was on the branch at the time.”
Deployment steps should be explicit about which environment they target. I use placeholders such as APP_ENV, DEPLOY_TARGET, and RELEASE_ID in examples because the names and values belong in the deployment system, not in a public article or a repository.
Let Salt describe the destination
SaltStack is a good fit for the machine-side work: packages, users, directories, service configuration, permissions, and running services. A state should describe the result we want, not a sequence of lucky shell commands that happened to work once.
That distinction matters when a deployment is repeated. A state that can be applied again without damaging an already-correct system is easier to recover, easier to review, and much less stressful when the first run is interrupted.
Keep secrets out of the artifact
Build output should not become a secret distribution mechanism. Credentials, tokens, and environment-specific values should come from the appropriate protected store and be rendered only where they are needed. Public examples should use placeholders, and the application should fail clearly when a required value is absent.
Use promotion as a control point
Not every successful build should immediately change production. Promotion provides a useful boundary for review, approval, and a final check that the artifact and configuration belong together. The pipeline can carry the release identifier; Salt can verify that the target state is compatible before applying it.
Test the awkward paths
The happy path is the least interesting part of deployment. Test a missing variable, an unavailable package mirror, a service that will not restart, a partially completed run, and a second application of the same state. Those tests reveal whether the system is actually recoverable or merely impressive when everything is healthy.
The result is a practical boundary: GitLab CI/CD provides the evidence and promotion flow, while SaltStack provides repeatable convergence on the destination. Neither tool has to pretend to be the other.
Current as of September 2026. Examples use placeholders intentionally; deployment names, hosts, credentials, and environment details should stay in the systems that manage them.
Leave a Reply