Giters

orenre / awesome-devops-and-aws

A collection of awesome things related to DevOps and AWS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Awesome DevOps and AWS Awesome CDK

A collection of awesome things related to DevOps and AWS

DevOps on AWS

Methodology

  • Follow The Twelve-Factor App principles. See also Applying the Twelve-Factor App Methodology to Serverless Applications

  • Create a release branch and apply hotfixes first to master and cherrypick to release branch. This is a Trunk-Based Development model, which Amazon strongly encourages internally - see “before we begin” in Implementing GitFlow Using AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy. Some exceptions are when a fix was already introduced to master branch somewhere, so in this case it’s faster to temporarily open the release branch for direct pull request (the “temporarily” can be enforced through JIRA and a CI system for example)

  • Consider Branch by Abstraction for major changes that take time and continue using Feature Toggles for deciding when to release

  • Test upstream dependencies based on their production at the least. A shift left approach would be to test upstream dependencies based on their staging environment (would incur additional costs for each service to support this)

  • Separate Continuous Delivery and [Continuous] Deployment processes - implement as 2 pipelines. This will enable a decision point as to which regions to deploy instead of all or nothing

    • Continuous Delivery pipeline will build the artifacts, run unit/integration tests (to keep development cycle fast with short feedback loop for developers if something fails at this stage), run system tests, capacity tests, performance tests and promote to staging for manual tests (e.g. manual QA and UAT)
    • [Continuous] Deployment pipeline will deploy to specified regions or all at once in rolling manner (to reduce blast radius of failed change), depending on the need. A central database is needed to track deployments and keep versions across regions in sync (e.g. do not deploy newer version in region B, while region A has an older one - upgrade region A first). Deployment might be triggered manually or automatically following the Continuous Delivery pipeline

  • ThoughtWorks Technology Radar - Techniques. Specifically, "Four key metrics": The thorough State of DevOps reports have focused on data-driven and statistical analysis of high-performing organizations. The result of this multiyear research, published in Accelerate, demonstrates a direct link between organizational performance and software delivery performance. The researchers have determined that only four key metrics differentiate between low, medium and high performers: lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. Indeed, we've found that these four key metrics are a simple and yet powerful tool to help leaders and teams focus on measuring and improving what matters. A good place to start is to instrument the build pipelines so you can capture the four key metrics and make the software delivery value stream visible

  • Use multiple accounts for different Software Development Life Cycle (SDLC) stages to reduce blast radius of configuration changes, security breaches, account or regional quotas (a.k.a. limits) and more. See Establishing your best practice AWS environment for more motivation and details

References

Mindset

IDE

Infrastructure as Code

CI/CD

Observability

About

A collection of awesome things related to DevOps and AWS

License:Creative Commons Zero v1.0 Universal