Deployability Fields

Within ArchRepo you can document one or more deployability mechanisms for your solution.

1. General Description

• Description
  • Purpose: Provide a high-level summary of the deployment approach for the solution. For larger solutions, you may have different deployment strategy for different building blocks. You can create different deployment profiles and relate to the relevant areas of the solution.
  • Guidance: Briefly describe how deployment is performed across environments and any notable deployment constraints or goals.
  • Example: “The solution uses a fully automated CI/CD pipeline to deploy updates across staging and production environments with zero downtime. Deployments include smoke testing and ensure regulatory compliance with GDPR.”

2. Deployment Strategies

• Deployment Strategy

  • Purpose: Specify the deployment strategy or strategies used for the solution.
  • Guidance: Enter the strategy that best describes how new changes are deployed. Examples include Blue-Green Deployment, Canary Release, Rolling Deployments, or Recreate.
  • Example: “Blue-Green Deployment is used to reduce downtime, ensuring uninterrupted operations during deployments.”

• Rollback Strategy

  • Purpose: Describe the approach for rolling back changes in case a deployment fails.
  • Guidance: Indicate the rollback mechanism, including whether previous versions, backups, or snapshots are used.
  • Example: “Rollback involves switching traffic back to the ‘Blue’ environment or restoring the last successful deployment.”

• Zero Downtime Deployment

  • Purpose: Indicate whether the deployment process ensures there is no downtime for users.
  • Guidance: Set to Yes if zero-downtime is a key requirement, and include details in other fields like Blue-Green Deployment.
  • Example: “True – downtime is avoided through load balancing and environment switching.”

• Deployment Pipeline Type

  • Purpose: Define whether the pipeline is automated, manual, or a combination of both.

3. Deployment Environments

• Supported Environments

  • Purpose: List the environments where deployments occur.
  • Guidance: Include all relevant stages such as Development, QA, Staging, and Production.
  • Example: ["Development", "QA", "Staging", "Production"].

• Environment Parities Maintained

  • Purpose: State whether the environments are identical in terms of configurations, dependencies, and provisioning.
  • Guidance: Maintaining parity ensures consistent performance and reproducibility across all stages.
  • Example: “Yes – All environments are consistent with Infrastructure-as-Code ensuring parity.”

4. Tooling

• Deployment Orchestration Tools

  • Purpose: Specify the tools used to orchestrate the deployment process.
  • Guidance: Include tools for managing automated or manual pipelines (e.g., Jenkins, AWS CodePipeline).
  • Example: “ArgoCD for orchestration of Kubernetes-based deployments.”

• Container Orchestration Tools

  • Purpose: Document the tools used for managing containerised applications.
  • Guidance: Specify tools such as Kubernetes, Docker Swarm, or equivalent.
  • Example: “Kubernetes is used for scaling and orchestrating containerised microservices.”

• Infrastructure Provisioning Tools

  • Purpose: Indicate tools used to provision and configure underlying infrastructure.
  • Guidance: Examples include Terraform, Pulumi, or AWS CloudFormation.
  • Example: “Terraform scripts automate infrastructure provisioning across AWS.”

• Configuration Management Tools

  • Purpose: Record tools used for managing system configurations.
  • Guidance: Include tools such as Ansible, Chef, or Puppet.
  • Example: “Ansible is used for automating configuration management.”

5. Deployment Metrics and Observability

• Deployment Frequency

  • Purpose: State how frequently deployments are expected to occur.
  • Guidance: Use terms such as Weekly, Daily, or On-Demand.
  • Example: “Deployments are made weekly during maintenance hours.”

• Deployment Failure Rate

  • Purpose: Highlight the percentage of deployments that fail within a given time frame.
  • Guidance: Use this measure to evaluate deployment reliability.
  • Example: “The current failure rate is under 2%.”

• Mean Time to Deploy

  • Purpose: Document the average duration for deploying a build.
  • Guidance: Provide times in hours or minutes (e.g., “1 hour”).
  • Example: “Mean deployment time is 45 minutes.”

• Mean Time to Recover Deployment

  • Purpose: Describe the average time taken to restore operations after a failed deployment.
  • Example: “Recovery from deployment failures takes an average of 30 minutes.”

6. Rollback and Versioning

• Rollback Enabled

  • Purpose: Confirm if rollback capabilities exist.
  • Example: “true – Rollback supported with automated version restoration.”

• Rollback Mechanism

  • Purpose: Explain how rollbacks are handled.
  • Example: “Database snapshots and artefact versioning are used for restoration.”

• Maximum Rollback Interval

  • Purpose: Specify the maximum time allowed before initiating rollback.
  • Example: “If deployment has not completed within 15 minutes, rollback is initiated.”

• Versioning Schema

  • Purpose: Define the schema for versioning artefacts or deployments.
  • Guidance: Examples include semantic versioning (e.g., v1.0.0) or Git commit hashes.
  • Example: “Semantic versioning used, e.g., v2.1.0.”

7. Security and Compliance

• Deployment User Privileges

  • Purpose: Highlight the level of privileges required to execute deployments.
  • Example: “Deployments are restricted to admin users within the CI/CD dashboard.”

• Secure Artefact Storage

  • Purpose: Confirm whether artefacts are securely stored and transmitted.
  • Example: “true – All deployment artefacts are stored in a private repository (e.g., AWS S3 with encryption).“

8. Testing During Deployment

• Smoke Tests Enabled

  • Purpose: State if basic checks are run to validate deployments.
  • Example: “true – Simple API and health-check smoke tests are executed post-deployment.”

• Canary Testing Enabled

  • Purpose: Confirm if canary testing is part of the deployment.
  • Example: “true – 5% of traffic is routed to the canary build.”

• Testing Tools

  • Purpose: List the tools used for deployment testing.
  • Example: “Cypress and Selenium used for functional testing.”

9. Blue-Green and Canary Configurations

• Blue-Green Switching Mechanism

  • Purpose: Document how traffic is switched between the “Blue” and “Green” environments.
  • Example: “Traffic is switched via a load balancer.”

• Canary Release Duration

  • Purpose: Specify how long the system monitors canary builds before scaling to full release.
  • Example: “Canary testing duration is 2 hours.”