Database Continuous Integration - Chapter 6 - From Dev to Prod and Back

By: Alex ​Podlesny

In this chapter: from development to production and from production to development workflow. 

If you landed on this page from search engine, we would recommend starting with the first chapter

Back in Chapter One, where we have discussed SDLC, we have introduced the realities of the production world. 

Many businesses built around one database or, perhaps, multiple databases, they grow together, expand and evolve through well know development cycles:  

  1. Develop new feature 
  2. Move it to production  
  3. Use a new feature until it becomes old  
  4. Come up with new ideas  
  5. Back to Step 1 

The big difference between CI for a product development and CI needed to support corporate production environment is a product of integration: "The Creature DNA" v.s. "The Creature" (check Chapter Two for more information). While "Creature DNA" can be sitting on a shelf and can be assembled and reassembled any time. The actual "The Creature" database could not be turned off, reassembled or changed, especially in the high-availability projects. Ironically over lifetime, very close to real life scenario, the Creature can get new properties that original DNA did not even had. Maintenance, performance tuning, constant flow of new data and hotfixes, hardware-software-network issue resolution, upgrades, configuration changes can quickly introduce mountains of differences in how both behave. 

If technologists want to deliver new functionality to running, potentially high-availability database, they need to look into the idea of incremental upgrades. Upgrades that slowly transform existing system into an adaptive and always evolving production environment with new functionality and without impact.  

When idea of continuous updates and continuous delivery of changes accepted, the next step is to set up a backflow of changes, unknown to developers, from the production environment back to the development. 

In such a transformed place:

  • the product of CI for a production environment can be a simple set of scripts that introduce new functionality - an upgrade
  • the goal of CI stay the same - is to make sure that by the time those scripts are ready to be deployed to production, there are:
    • no known integration issues 
    • a minimal as possible risk of impact 

Production lifecycle should include steps to push all production changes continually back to development environments and close the potential code difference gap between development and productions environments: 

Dev --> Prod Prod --> Dev
  1. develop new feature 
  2. move it to production
  3. use new feature until it becomes old  
  4. come up with new ideas  
  5. back to Step 1 
  1. recognize a change in production 
  2. script that change 
  3. deliver this change back to source code repository in development environment
  4. back to Step 1

 

With dev2prod and prod2dev vision let’s move to the next chapter and examine production CI 

 

Sunday, January 4, 2015 4:30: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)