Skip to content
ATLAS Releasestrategy 2 Trunkbaseddevelopment

ATLAS Releasestrategy 2 Trunkbaseddevelopment

Andi Lamprecht Andi Lamprecht ·· 2 min read· Accepted
ADR-0058 · Author: Sybil Melton · Date: 2025-02-07 · Products: platform
Originally ADR-0042 ATLAS-ReleaseStrategy-2-TrunkBasedDevelopment (v3) · Source on Confluence ↗

Release Strategy - Trunk based development

Context

Atlas product Continuous Integration / Continuous Delivery (CI/CD) strategy is aligned with DroneUp trunk based development strategy. In this approach source of truth and latest code is the trunk branch. This code then need to pass through dev and stage environment checks until it reaches the prod, where it produces a value for consumer services

Continuous Integration

Invalid Image Path

The Continuous Integration process begins with developers first committing their code locally and subsequently pushing it to a private feature branch. At this stage, they have the option to either generate an ephemeral test image from the code or incorporate it into the main codebase (trunk). Prior to merging, the code must undergo a review and receive approval from another developer as well as pass a basic quality checks.

Continuous Deployment

Invalid Image Path

  1. Stage 1 - Development deployment workflow

The software deployment process begins with merging the code into the trunk, which triggers the CircleCI dev deployment workflow. This workflow deploys the code into the infrastructure created on the development cluster. If the code has made any changes within the pipeline, a flush run is initiated. Nightly recurring checks include integration tests, system tests, and data quality tests.

To advance to the next stage, a manual approval from the developer is required.

  1. Stage 2 - Staging deployment workflow

Following this approval, the CircleCI staging deployment workflow is triggered, deploying the code into the infrastructure on the staging cluster. Once again, if there are changes in the pipeline code, a flush run is triggered, and the nightly checks are performed.

In the staging environment, the code is monitored to ensure it runs correctly in a production-like setting. If all recurrent tests pass, approval from both the Product Owner (PO) and the development team is necessary to move on to the next stage.

  1. Stage 3 - Production deployment workflow

Finally, the CircleCI production deployment workflow is initiated, deploying the code into the production infrastructure. Once again, if there are changes in the pipeline code, a flush run is triggered to refresh a data. Continuous monitoring for changing data and warnings related to unsupported values are handled by frequent Data Quality tests.

Last updated on