Please enable JavaScript.

Coggle requires JavaScript to display documents.

Technical practices (Enable and practice continuous integration (Branching…

- - - - disable remote logins to production servers
        
        routinely kill and replace production instances, ensuring that manually applied production changes are removed
- - - - fully document the steps in the deployment process
      - Simplify and automate as many of the manual steps as possible, such as:
        Packaging code in ways suitable for deployment
        Creating pre-configured virtual machine images or containers
        Automating the deployment and configuration of middle ware
        opying packages or files onto production servers
        Restarting servers, applications, or services
        Generating configuration files from templates
        Running automated smoke tests to make sure the system is working and correctly configured
        Running testing procedures
        Scripting and automating database migration
      - re-architect to remove steps, particularly those that take a long time to complete.
      - We also want to not only reduce our lead times but also the number of handoffs as
      - create deploymebnt pipeline (Jenkins, etc.)
        
        Deploying the same way to every environment
        
        Smoke testing our deployments
        
        Ensure we maintain consistent environments
      - when any problems occur during deployment, we pull the Andon cord and swarm the problem until the problem is resolved
    - - no statistically significant difference in the change success rates between organizations where Development deployed code and those where Operations deployed code.
      - INTEGRATE CODE DEPLOYMENT INTO THE DEPLOYMENT PIPELINE
        
        Ensure that packages created during the continuous integration process are suitable for deployment into production
        
        Show the readiness of production environments at a glance
        
        Provide a push-button, self-service method for any suitable version of the packaged code to be deployed into production
        
        Record automatically, for auditing and compliance purposes, which commands were run on which machines when, who authorized it, and what the output was
        
        Run a smoke test to ensure the system is operating correctly and the configuration settings, including items such as database connection strings, are correct
        
        Provide fast feedback for the deployer so they can quickly determine whether their deployment was successful (e.g., did the deployment succeed, is the application performing as expected in production, etc.)
  - - - The Canary and Cluster Patterns
        
        The canary release pattern automates the release process of promoting to successively larger and more critical environments as we confirm that the code is operating as designed.
      - Cluster Immune System Release
        
        expands upon the canary release pattern by linking our production monitoring system with our release process and by automating the roll back of code when the user-facing performance of the production system deviates outside of a predefined expected range
      - The Blue-Green Deployment Pattern
        
        To release a new version of our service, we deploy to the inactive environment where we can perform our testing without interrupting the user experience. When we are confident that everything is functioning as designed, we execute our release by directing traffic to the blue environment.
        
        Dealing with Database Changes
        
        Decouple database changes from application changes
        
        Create two databases (i.e., a blue and green database):
    - - Implement Feature Toggles
        
        Easy Roll-back
        
        Graceful degradation of quality of service
        
        Increase our resilience through a service-oriented architecture
      - Perform Dark Launches
        
        we deploy all the functionality into production and then perform testing of that functionality while it is still invisible to customers
- - - - When we implement strangler applications, we seek to access all services through versioned APIs, also called versioned services or immutable services.
    - - we create an abstraction layer between the areas that we are changing. This enables evolutionary design of the application architecture while allowing everybody to work off trunk/master and practice continuous integration.
    - - Monolitic v1
      - Monolitic v2
      - Microservices
- - - - building our deployment pipe
        
        all code checked in to version control is automatically built and tested in a dedicated production-like environment
        
        Commit stage (automated)-> acceptance stage(automated)-> Exploratory testing -> UAT -> Production
      - This information also helps us fulfill evidence requirements for audit and compliance purposes, with evidence being automatically generated as part of daily work.
    - - Unit test
      - Acceptance test
        
        After: available for manual testing (e.g., exploratory testing, UI testing, etc.), as well as for integration testing.
      - Integration test
    - - Whenever we find an error with an acceptance or integration test, we should create a unit test that could find the error faster, earlier, and cheaper
      - any errors should be found with the fastest category of testing possible -> Testing pyramid
      - Run tests in paralell. Ex:
    - - TDD
      - BDD
      - ATDD
    - - enable all our testers work on high-value activities that cannot be automated, such as exploratory testing or improving the test process itself.
      - automating only the tests that genuinely validate the business goals we are trying to achieve
    - - build automated tests to validate that our environments have been built and configured properly
        
        test that our environments are configured and operating correctly (e.g., encoding environment tests into cucumber or gherkin tests).
        
        run tools that analyze the code that constructs our environments (e.g., Foodcritic for Chef, puppet-lint for Puppet)
        
        run any security hardening checks as part of our automated tests to ensure that everything is configured securely and correctly (e.g., server-spec)