CI/CD: from a Git commit to a controlled deployment

Understanding DevOps as a work organization

DevOps brings together development and operation around a delivered and maintained product. It's not just adding a pipeline tool. Teams must share expectations on quality, deployments, monitoring and incidents. Automation can speed up a bad process if responsibilities remain unclear. Start by describing the change path: who proposes, who verifies, what artifact is delivered, and how success is confirmed. CI/CD makes this path repeatable and observable, but business decisions and risk levels remain to be defined.

Continuous integration verifies shared changes

The CI runs checks when changes are proposed or integrated. Depending on the project, she installs dependencies, checks types, runs tests, and builds the product. Place quick checks early to provide useful feedback. Tests should cover important rules rather than simply reproducing the implementation. A green execution only proves what is actually verified. If no test controls access between organizations, the pipeline does not guarantee this isolation, even if hundreds of other assertions pass.

Differentiate between continuous delivery and deployment

Continuous delivery maintains a release ready for deployment, possibly with final validation. Continuous deployment also automates this production when the defined conditions are met. The choice depends on risk and context, not a universal maturity ranking. A low-risk internal service and a payment application do not necessarily require the same control. Human validation must relate to a precise version with visible results. Asking for agreement without identifying the change and its consequences does not make the deployment truly controlled.

Organize a GitHub Actions workflow

An event triggers a workflow which contains jobs, themselves composed of steps. Jobs can be independent or dependent on the success of other jobs. A runner provides the execution environment. Clearly define the triggers: pull request, push on a branch or manual action. Avoid multiple competing deployments overriding each other unchecked. Caches speed up installations, but should not make the result dependent on stale files. Keep readable logs so that a compilation failure can be distinguished from a network or runner authentication problem.

Build once and identify the artifact

Associate each image or package with a stable identifier, such as the commit. The tested artifact must be the one delivered. If the server rebuilds with different dependencies, the pipeline results no longer accurately cover what is running. Store artifacts in a suitable register or space and define their retention. A label named latest can be convenient, but is not sufficient for investigating an incident. You must be able to find the exact version, its sources and the checks that were carried out before putting it into production.

Protect pipeline secrets and permissions

A pipeline can have access to the registry, servers, and deployment keys. Grant only the necessary permissions to each job and separate sensitive environments. Untrusted contributions should not automatically obtain production secrets. Do not print credentials and check external scripts executed. Pipeline actions and dependencies are also part of the software chain. Define who can modify workflows and deployment settings. A well-protected application can be compromised if its delivery chain has access that is too broad and poorly controlled.

Prepare migrations and compatibility

Delivery sometimes includes a database modification, configuration, or API contract. Check the order of application and the coexistence of versions. A destructive migration can prevent a return to previous code. When possible, prefer a compatible transition: add, migrate gradually then remove after verification. Backups must be usable and their restoration assessed. Don't launch parallel migrations without a coordination strategy. The pipeline should explain what happens in the event of a partial failure, instead of treating each step as independent of all others.

Verify the deployment with a useful journey

A started process and an open port are not enough. Check a relevant route, then a representative journey: view a product, log in or open an important page depending on the system. These smoke controls must remain rapid and avoid real undesirable effects. Tests that create data must use a controlled scope. Then observe errors and performance. A deployment can be technically successful while introducing a functional regression or a significant increase in latency. Define signals that trigger intervention or recovery.

Prepare for a realistic return

Retain the previous artifact, necessary settings, and a documented procedure. A rollback must take into account external data and services: it does not cancel an email already sent or an irreversible migration. Test the procedure in a representative environment. For some changes, a forward fix is ​​safer than reverting to old code; this choice must be anticipated. Measure restoration time and the degree of intervention required. A rollback button without dependency checking can give the impression of security without providing a real solution during the incident.

Advancing the pipeline without making it opaque

Start with the necessary controls and a well-identified deployment. Add steps when they cover a real risk, not to make the configuration file longer. Track delivery frequency, failures, return times and recovery times with context. Tuplify Studio can build Next.js, NestJS, Angular, or Spring Boot project pipelines, with Docker build and delivery checks. Documentation and readability count: another person must be able to understand the pipeline and intervene without depending exclusively on the person who created it.

Workshop: practicing delivery and its backtracking

On a representative environment, deliver an identified version and verify a user journey. Then introduce a monitored defect that should be detected by post-deployment checks. Run the scheduled recovery and confirm the actual active version and then the data status. Measure the time and necessary interventions. Verify that someone other than the pipeline author can follow the documentation. This exercise reveals the implicit steps and secrets held in a single position. It also makes it possible to distinguish a simple code return from a change affecting a migration or an external system, the consequences of which do not disappear with the old image.

Frequently asked questions: speed and confidence

Does more testing always make the pipeline better? Useful tests cover risks and provide a reliable result. Slow, redundant or unstable controls can reduce confidence.

Can we deploy as soon as the build passes? Compilation alone does not evaluate critical permissions, data and paths. Delivery criteria must match the product.

Can caching replace a reproducible installation? It speeds up operations, but should not hide a missing dependency or old artifact. Test a cache-free path regularly. A pipeline should maintain a clear relationship between sources, dependencies, artifact under test, and deployed version, even when speed optimizations are enabled.