Skip to content

Phase 0: Foundational Improvements for Deployment and Development

1. Introduction

This document outlines the objectives and outcomes of Phase 0, a foundational phase focused on standardising deployment processes, segregating environments, and establishing disciplined developer workflows. The successful completion of this phase is a prerequisite for the advanced infrastructure migration detailed in Phase 1.

The primary goal of Phase 0 is to move from ad-hoc, inconsistent deployment methods (beyond production) to a structured, automated, and repeatable system. This will address key operational risks and improve developer velocity and code quality. Measurement of success criteria to be determined.

2. Current Challenges

The development and deployment lifecycle currently faces several challenges:

  • Inconsistent Deployment Methods: While deployment scripts (deploy.sh/deploy.ps1) exist, their use is not standardised. Deployments are performed manually from developers' local machines and are limited to the staging environment, leading to a lack of visibility and control.
  • Lack of Environment Segregation: Only a staging environment is formally available for testing. The absence of a review environment for feature branches means that isolated testing is not possible, increasing the risk of conflicts.
  • Monolithic Build Logic: Deployment scripts and configurations are packaged with the application code, meaning the infrastructure and deployment logic cannot be worked on independently of the app and often require a PR. This interrupts developers and delays all changes.

3. Core Objectives of Phase 0

To address these challenges, Phase 0 focuses on three core objectives:

3.1. Deployment Standardisation

  • Goal: To standardise the deployment method and expand environment capabilities.
  • Implementation:
  • The current deployment scripts will be replaced with a build orchestrator deployment tool; the one currently in use for production is DeployHQ.
  • Benefit: All deployments will be consistent and auditable. The review environment will allow for parallel testing of features without interference.

3.2. Environment Segregation

  • Goal: To establish clear, isolated boundaries between staging, review, and production environments.
  • Implementation:
  • Define separate database namespaces for each environment (staging-database, review-database, production-database).
  • Benefit: This will enable safe, isolated testing of new features without impacting other environments and prevent data corruption.

3.3. Improving Developer Workflow

  • Goal: To streamline the development process by enforcing consistency and automating routine checks.
  • Implementation:
  • Centralised Build System: A .mg-build-system Git submodule will be created to house all deployment scripts, Docker configurations, and Kubernetes manifests. This will decouple application code from deployment infrastructure.

3.4. GitOps-Based Deployment Flow

  • Goal: To implement a GitOps-based workflow that automates deployments based on Git branching and tagging conventions.
  • Implementation:
  • Automated Staging/Review Deployments: Configure the CI/CD system to automatically deploy any code pushed to branches with prefixes like feature/, fix/, or hotfix/ to a staging environment.
  • Controlled Production Deployments: Production deployments will be triggered by creating a semantic version tag (e.g., v1.2.3). This process will require manual approval to proceed, ensuring that only validated and authorised changes reach production. This can be limited to authorised individuals if necessary.
  • Benefit: This will create a clear, auditable, and automated path to production, reducing manual effort and the risk of human error. It will also enforce a disciplined release process using semantic versioning.

4. Key Implementations

  • .mg-build-system Submodule: This will be the cornerstone of Phase 0, acting as the single source of truth for all deployment-related infrastructure. It will be version-controlled independently of the application, allowing the DevOps team to roll out updates to the build system without requiring immediate changes from the development team.

  • Standardised Deployments: The deploy.sh and deploy.ps1 scripts will be replaced by a more rigid standardised deployment process centred around gitops. There will still be ad-hoc/on demand deployments available where required although this will be the exception rather than the rule.

  • Dynamic Environment URLs: The system will automatically generate URLs based on the branch and environment, such as app.{branch-name}.{environment}.methodgrid.com, making it intuitive to access any deployed version. For production this would be subsituted with customer name like app.{customer}.methodgrid.com (depending on customer action)

5. Success Criteria for Phase 0

This phase will be considered complete upon meeting the following criteria:

  • [ ] Standardised Deployments: All deployments to all environments are executed exclusively through the chosen deployment tool (e.g., DeployHQ).
  • [ ] Centralised Logic: All deployment logic is consolidated within the .mg-build-system submodule.
  • [ ] Proven Environment Segregation: The separation of database namespaces and branch-specific deployments is validated and functioning correctly.

6. Transition to Phase 1

The successful completion of Phase 0 will establish a stable and predictable for our development and deployment processes. This standardisation and automation will significantly de-risk future infrastructure changes.

This will put us in a strong position to proceed with Phase 1: Staging Proof of Concept, which will focus on migrating our containerised services from the current deployment system to a more scalable and robust Helm-based architecture in Kubernetes. The discipline and tooling to be established in Phase 0 will be critical for the success of this next major step.

7. Tooling Selection ##

Where possible:

  • existing tooling will be utilised unless there is a justifiable reason to swap
  • environment naming and app structure will be left alone

Possible gaps:

  • No GitOps controller present so kubernetes has no single source of truth
  • Automated setup of the environments themselves must be standardised and moved to DeployHQ
  • Data needs sanatising when staging3 re-built
Last modified by: Unknown