Database Continuous Integration - Chapter 7 - Production CI

In this chapter: taking continuous integration process to production. 
 
If you landed on this page from search engine, we would recommend starting with the first chapter 

Here is how CI practice can be implemented as backbone of the production process:  

  1. Maintain source code repository:
    • Follow the same principles outlined in Chapter 4, plus: 
    • Create separate Version Control System (VCS) folder (or branch) to store all objects scripted from production system; this folder becomes a "Base Source Code" for you database. 
    • Create separate VCS folder (or branch) for each release that is currently in the queue to go to production, all development changes represent a "Delta Source Code". The Delta is where all developers are contributing their code until feature is ready to go to the next step in the adopted SDLC process.  
       
  2. Commit changes often, never longer than a day:
    • Follow the same principles outlined in Chapter 4, plus: 
    • Set up automated process that script all production database objects and core metadata in a production database, and then checks all those scripts to VCS repository on a daily basis. 
    • Yes, every night automated process should collect and check-in production code into VCS. Over time, it becomes a history of all production changes that can be used to monitor the state of the production system.
       
  3. Every commit to the master branch should be built:
    • Follow the same steps outlined in Chapter 4, plus: 
    • All changes from the production environment should be incorporated into the build to help control assumptions. 
    • In addition to a brand-new-fresh-and-clean database artifact that needed for development, a production oriented CI process should produce a Delta Release artifact, which later is used to update production system automatically. 
       
  4. Build Automation:
    • Build automation should become the backbone of production delivery process with multi-layer, multi-environment delivery system.  
       
  5. Make sure that artifacts are available as installation packages
    • Follow the same principles outlined in Chapter 4 
    • Installation package should be easily consumable by existing and home grown solutions. Keep your options open, tools are changing very rapidly, make sure you have a way to adopt a new approach  
       
  6. Build process should be fast:
    • Follow the same principles outlined in Chapter 4, plus: 
    • Production CI process can quickly become multi dependent and layered, look for ways to improve delivery time for each part of the process and for the process as whole;  
    • Manage the risk of "never building final product", minimize the impact from future releases that currently are actively developed. Isolate, separate, branch, minimize and simplify each release. Try to achieve a "one deployment a day" goal, when you are there improve too many per day, if you are not there re-think re-engineer, changeā€¦ 
       
  7. Automated Unit Testing:
    • Follow the same principles outlined in Chapter 4, plus: 
    • Unit Test should become paramount requirements. Any changes in code, no matter how small should have a unit test for that change.
    • Test Driven Development anybody? why not? 
    • Focus on code coverage, improve it with every commit to VCS. 
    • Introduce code review and sign-in for every pull request. 
    • Please, somebody, check my code! 
    • Introduce integration tests. Developers cannot mock forever. Test the actual code you build. 
    • Create and automated process for any steps that run multiple times, those steps should not be executed manually. 
       
  8. Available Build Results:
    • Follow the same principles outlined in Chapter 4, plus: 
    • Something fails all the time; it is human to make mistakes. 
    • Install TVs in the hallways, install them in the kitchen, hang them on an empty wall right by Steve Job's picture to increase visibility. Let your build process inspire your team.
       
  9. Keep the set of pre-production environments. Configure automated deployments to them
    • Create as many environments as needed, as many as you can afford;
    • Use virtualization, use instances;  
    • Automate provisioning;  
    • Reuse existing hardware, move where it is needed, convert it to build agents, if you do not need it - donate to another team; 
    • Configure automated deployment to all of your environments 
    • Use the same tools to deploy to production and to pre-production. You want to know what fails before it fails in production; 
    • Do not release anything if build fails, even if it is one-insignificant-tiny-tiny unit test, know that this unit test was there for a reason; 
    • If something failed - stop, think, create a unit test to check for failing conditions, change your process to prevent future failures; 

      What to deploy? What artifacts?
      • the primary deployable artifacts in the production CI is the Delta Source Code that contains scripts to load well-tested code or well known by now data. 
         
  10. Tune the process to the point of continuous deployment to production
    • At first, define what is the "Auto-Deployable Release" that team can accept. 
    • Create guidelines to identify Manual Release. Manual release - is the release that should not be deployed automatically. Make guidelines available for every team member. 
    • Try to get code reviews, documentation, sign-offs, approvals and other paperwork while new product is moving through development pipeline. By the time, it reaches the UAT environment you would know if the release is auto- or manually-deployable.  
    • Do not push the release to production if anything fails in a build, even if it is one-insignificant-tiny unit test. 
    • Use the same tools to deploy to production and to pre-production environments. Deployment tools should use the same technology, the same workflow, and the same process to deliver changes. You want to catch failures before they take down production environment;    
    • Use the same tools to deploy automated and manually released with the main difference being a step that requires human interaction - push a button to deploy Manual Release  to prod. 

 

Be realistic - Not everything could (nor should) be automated - just tune the process to the point of continuous deployment to production of all the changes that can be automated. 

 

 

Sunday, January 4, 2015 4:32:00 PM
Comments are closed on this post.
  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google

Statistics

  • Entries (13)
  • Comments (0)