Developer Image Lifecycle Guide

Introduction

This document is the official technical guide for all Opstella Product Developers. It covers the image tagging strategy, the CI/CD promotion flow, and the retention policies that govern our container images. Adhering to this process is crucial for traceability, stability, and cost management.

CI/CD Promotion Flow

Our release process is designed to move builds from development to production through three distinct channels. Each promotion is a deliberate step with specific rules.

Dev Channel (CI/CD Builds)

What it is: Images are built automatically by the CI/CD pipeline on every merge to the main development branch. This channel is for active development and initial testing.

Tagging Rule

The CI pipeline must tag all 17 images with the format: major.minor.patch-shortcommitsha (e.g., 5.2.5-a1b2c3d4). This is our mechanism for tracing every image back to a specific commit.

Note on Retention: dev images are automatically pruned after 14 days to manage costs.

Staging Channel (Release Candidates)

What it is: At the end of a sprint (every 14 days), a specific dev build is promoted to staging. This version is used by the Customer Success team for QA, partner alpha testing, and demos.

Promotion Process

Promotion to Staging is a semi-manual process. A release manager or technical lead will re-tag the approved dev build with its version number (e.g., 5.2.5). Only the 3 most recent staging versions are kept.

Stable Channel (Official Customer Release)

What it is: This is the official, production-ready version for customers. Promotion to this channel is a deliberate business decision, not just a technical one, and requires approval from the Product Owner.

Production Release

Do not promote to stable without formal approval. This process involves re-tagging the validated staging image (e.g., 5.2.4) and updating the floating tags (5.2, stable) to point to the new release.

Key Developer Principles

• Traceability is Mandatory: The shortcommitsha tag on dev builds is not optional. It is essential for debugging and identifying which code is running in any environment.
• Respect the Retention Policy: The 14-day policy on dev images is our primary method for controlling storage costs in GCP Artifact Registry. Do not rely on dev images for long-term storage or demos; use staging for that.
• Protect the Stable Channel: The stable channel is immutable and represents our promise to customers. The promotion process is gated for a reason — to ensure we never ship un-vetted or broken code.