Developments in Blockchain Security & Privacy

Blue Green Success Depends On Data Compatibility

Using a blue green deployment strategy in a software testing environment reduces downtime and eliminates risk. Unfortunately, data compatibility issues can sometimes occur, allowing continuous delivery to become continuous stagnation. Developers can safeguard against this occurrence by understanding how to resolve data incompatibility issues.

Blue Green Review

A blue green deployment strategy is performed by running two identical production environments, a current version (green) and a testing version (blue). In brief, testers increase user traffic to the blue version while seeking to discern any errors. Using this rolling strategy, testers can rollback to the green version’s last update if any errors are detected.

Once nearly all traffic has safely moved to the blue version, they can shut down the (older) green version production environment. Keeping in line with the Continuous Deployment concept, this production cycle starts up once again (with the previous blue version now being labeled the green version).

Since switching between blue green environments is immediate, users experience zero downtown (to the point they don’t even notice the new environment). And since testing occurs during the production phase, developers are assured that the application is ready for the real-world environment.

Data Compatability Issues

Applications depend on persistent data to run successfully. Consequently, two copies of a data layer are created to facilitate data sharing and enable live data migration between machines. These data layers are especially important in a testing environment, where a bug may break the working (production) version.

Nonetheless, during the physical switch to a blue production environment, it’s possible that all data related to any current transactions occurring will be lost. Simply put, data produced by an application’s new code may fail to be compatible with the old code (whether in a database, disk, or cache). This is why backward compatibility must be assured.

Although data incompatibility issues are usually temporary, their potential to create havoc should not be dismissed (as anyone who has lost data will attest). As a safeguard, OpenShift suggests that developers run their application’s old and new code at the same time in a controlled test environment (much like an A/B deployment). They will want to make sure that user data migrating to the blue version does not cause green version to fail.

Database Schema Incompatibility

The most common data compatibility issues are related to database schemas. In his BlazeMeter blog, Iddo Greenberg suggests what to do if a database field name must be changed from “user_name” to “username”.

Release an intermediate version of the code, that can find and work with both “user_name” and “username” with some logic around it.
Run data migration – rename the field to “username” across all records/documents in the database (this can take seconds or days, it depends on the dataset size). Release the final version of the code, supporting only “username”, and remove completely the old code supporting “user_name”.

Martin Fowler describes another way to handle database schema changes:

The trick is to separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support both the new and old version of the application, deploy that, check everything is working fine so you have a rollback point, then deploy the new version of the application. (And when the upgrade has bedded down remove the database support for the old version.

Note: Refactoring is, “a disciplined way to restructure code. The basic idea is that you make small changes to your code to improve your design, making it easier to understand and to modify. Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach to programming. See also  www.refactoring.com,

Concluding Remarks

Continuous Delivery (CD) is a critical component to DevOps, as its fully focused on quickly readying software for production and deployment. And a blue green deployment strategy is the most notable methodology for achieving CD. Thus, understanding how to overcome an incompatible database schema may be critical to keeping DevOps moving forward. Suggestions welcome on this post.


Add Your Comment

* Indicates Required Field

Your email address will not be published.

*