Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-17T04:36:29Z

Wli29: /* Variation */

<font size="5"><b>Blue-Green Deployment</b></font>

<i>This article is a part of a writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref> </i>
<p>
Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.
</p>
__TOC__

=='''Background'''==
<p>     Software applications are becoming more and more complex. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology<ref>http://en.wikipedia.org/wiki/Agile_software_development</ref> has reduced release-time of new piece of code. On an average, Amazon is pushing changes to production every 11.6 seconds<ref>https://www.youtube.com/watch?v=dxk8b9rSKOo</ref>. Google and Facebook <ref>http://www.infoq.com/presentations/Facebook-Release-Process</ref>are releasing frequent changes to production. With new updates and features going into production at such a remarkable frequency, a need was felt to automate production deployment. </p><p>     More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery <ref>http://en.wikipedia.org/wiki/Continuous_delivery</ref> is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time".
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.</p>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
<p>    
Green environment is used to deploy all the new updates and run tests. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy is generated from Blue system and the moment when it is made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts <ref>http://www.infoq.com/articles/db-versioning-scripts</ref>. Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without losing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.</p>
<p>    
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features are blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
</p>

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Disadvantages'''==
===Database Migration===
As explained before, we need two databases servers. If things are not planned properly, users may easily end up working against an old Green database. The database migration during transition should be kept a minimal as possible. System should be made read only for most of the operations right before transition starts. Load any remaining data changes from the blue to the green, that may have occurred during transition (which should be relatively small, and a quicker operation in theory). Though a perfect zero downtime cannot be achieved using this, but a near zero downtime can be easily achieved.
<br/>
Overall, database changes should be rolled out incrementally. Many organizations, which deploy multiple times a day, don't roll out database changes frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily" (data will migrate as it’s used). If one need to roll back at this point, it can be done without a need to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and everything look perfect, apply the update script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

===Financial Burden===
Maintaining two identical production environments require a lot of space and computational resources. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environments. Virtual machines can be used to maintain two separate identical environments as well. Not only system, but many applications have huge databases, and maintaining two copies is a huge financial commitment.

=='''Examples'''==
==='''Blue Green deployment on Amazon AWS'''===
<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>
==='''Variation'''===
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing<ref>http://martinfowler.com/bliki/CanaryRelease.html</ref>. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:facebook.jpg]]</div>
<br/>
An interesting extension of this technique is the [http://www.slideshare.net/bgdurrett/continuous-deployment-at-lean-la cluster immune system]. This system monitors business metrics as a new version is being rolled out through a canary releasing system. It automatically rolls back the deployment if any parameters exceed tolerance limits, emailing everyone who checked in since the last deployment so that they can fix the problem.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:58:18Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Intuitively, you need to implement two databases on two seperate servers. You could very easily have green users working against a set of gold data in a green database. Sometime relatively close to when you would want to flip the router, you would run whatever ETL processes would be necessary to populate the green database with data from the blue database. Then, just before you actually flip the router, you would stop any further changes to the blue database data. Then load any remaining data changes from the blue to the green, that may have occurred since you initially transferred the data (which should be a relatively small, and much quicker operation in theory). While you wouldn’t have a “zero-downtime” scenario doing it this way, it could be very close to one. However, maintaining two identical production environment requires a lot of space and computational resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lots of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.
<br/>
Overall, database changes should be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

===Practical Issue===
Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:facebook.jpg]]</div>
<br/>
An interesting extension of this technique is the [http://www.slideshare.net/bgdurrett/continuous-deployment-at-lean-la cluster immune system]. Developed by the engineers at IMVU, this system monitors business metrics as a new version is being rolled out through a canary releasing system. It automatically rolls back the deployment if any parameters exceed tolerance limits, emailing everyone who checked in since the last deployment so that they can fix the problem.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:55:10Z

Wli29: /* Challenges */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Intuitively, you need to implement two databases on two seperate servers. You could very easily have green users working against a set of gold data in a green database. Sometime relatively close to when you would want to flip the router, you would run whatever ETL processes would be necessary to populate the green database with data from the blue database. Then, just before you actually flip the router, you would stop any further changes to the blue database data. Then load any remaining data changes from the blue to the green, that may have occurred since you initially transferred the data (which should be a relatively small, and much quicker operation in theory). While you wouldn’t have a “zero-downtime” scenario doing it this way, it could be very close to one. However, maintaining two identical production environment requires a lot of space and computational resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lots of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.
<br/>
Overall, database changes should be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

===Practical Issue===
Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:facebook.jpg]]</div>
<br/>
An interesting extension of this technique is the [http://www.slideshare.net/bgdurrett/continuous-deployment-at-lean-la cluster immune system]. Developed by the engineers at IMVU, this system monitors business metrics as a new version is being rolled out through a canary releasing system. It automatically rolls back the deployment if any parameters exceed tolerance limits, emailing everyone who checked in since the last deployment so that they can fix the problem.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:47:53Z

Wli29: /* Variation */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:facebook.jpg]]</div>
<br/>
An interesting extension of this technique is the [http://www.slideshare.net/bgdurrett/continuous-deployment-at-lean-la cluster immune system]. Developed by the engineers at IMVU, this system monitors business metrics as a new version is being rolled out through a canary releasing system. It automatically rolls back the deployment if any parameters exceed tolerance limits, emailing everyone who checked in since the last deployment so that they can fix the problem.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:44:27Z

Wli29: /* Variation */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:facebook.jpg]]</div>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:43:46Z

Wli29: /* Database Migration */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:43:03Z

Wli29: /* Variation */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:42:45Z

Wli29: /* Challenges */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

File:Facebook.jpg

2015-02-09T00:40:22Z

Wli29:

CSC/ECE 517 Spring 2015/ch1a 13 MA

2015-02-09T00:39:42Z

Wli29: /* hstore Functions */

<font size="5"><b>Postgres H-Store</b></font>

PostgreSQL is a powerful, open source object-relational database system based on [http://db.cs.berkeley.edu/postgres.html POSTGRES, Version 4.2], developed at the University of California at Berkeley Computer Science Department<ref> http://www.postgresql.org/docs/9.4/interactive/intro-whatis.html</ref>. It is fully [http://en.wikipedia.org/wiki/ACID ACID(Atomicity, Consistency, Isolation, Durability)] compliant,has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and [http://www.postgresql.org/docs/manuals/ exceptional documentation].<ref>http://www.postgresql.org/about/</ref>

An enterprise class database, PostgreSQL boasts sophisticated features such as [http://en.wikipedia.org/wiki/Multiversion_concurrency_control Multiversion concurrency control (MVCC)], [http://en.wikipedia.org/wiki/Point-in-time_recovery Point in time recovery], [http://en.wikipedia.org/wiki/Tablespace Tablespaces], [http://en.wikipedia.org/wiki/Savepoint Savepoints], asynchronous replication, online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data.

One of the great strengths of PostgreSQL is extensibility. Just as the [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] has become more than a way to just run Java—spawning languages such as Clojure and Scala—PostgreSQL has become more than just a home to relational data and the SQL language.

PostgreSQL has a number of ways of storing loosely structured data — documents — in a column on a table.
*hstore is a data type available as a contrib package that allows the user to store key/value structures just like a dictionary or hash.
*You can store data in [http://www.json.org/ JSON] format on a text field, and then use PLV8 to JSON.parse() it right in the database.
*There is a native xml data type, along with a few interesting query functions that allow you to extract and operate on data that sits deep in an XML structure.

We would be focusing on hstore in this document. hstore is a key value store within Postgres. It can be used similar to a dictionary within another language, but it’s specific to a column on a row.

__TOC__

=='''Background'''==

Hstore is a schemaless key value column in Postgres. It's perfect if the users need to store attributes for an object but aren't quite sure what the schema should be. In a scenario where a user starts selling 'Products' that have an author and an ISBN, if he wants to start selling cameras, or computer equipment he'll need to store other things like amount of ram or manufacturer. With hstore, the same column can be used for both sets of data, no migrations or schema changes needed. hstore is really useful for saving attributes on models. If we need to store all the settings for a particular set of users, this would be typically done in a separate model (or on the User model). Each setting would be an additional column. Instead of adding columns each time a new setting has to be created, a single hstore column could be created and used. It's much more flexible and doesn't require migrations each time something new has to be stored.

hstore enables the users to build better apps faster without sacrificing the power, reliability, and flexibility of the underlying PostgreSQL storage engine. By using hstore, the users will be able to leverage the flexibility and agility of schema-less data stores in existing environments. Although hstore is a mature, stable solution, it has recently been gathering widespread excitement. Support for hstore is available today in many popular languages and frameworks, including plugins for Django, Rails/ActiveRecord, Sequel, and Node.js.

In Rails hstore can be used like a hash, with any key and any value input. Once it's stored the keys or values can be queried. hstore behaves much like a serialized hash column. The main difference is performance, since hstore is storing the keys and values natively in Postgres, queries run much much faster. Rails 4 supports the hstore column type, until then a gem has to be used.

=='''Potential Applications'''==

What should hstore be used for? hstore is suitable for use in cases where most of the users' data is [http://en.wikipedia.org/wiki/Data_normalization normalized], but there may be bits of data related to models that may need to be changed frequently and the user doesn’t prefer to run database migrations too often, thus changing the structure of the database and possibly requiring the site to come down.
For example, assume a user receives information from an API that may change its responses without providing a backward-compatible, unchanging structure (inserting new keys in its JSON responses, for example). This may not be all that common with public APIs, but with internal projects this can happen rather frequently. Perhaps the user wouldn’t want to discard this data, but without writing a migration and making room for new data, he won’t be able to keep it.
Another possibility could be user preferences – Any user may not necessarily want 10-30+ rows per user in a giant join table for user preference data and perhaps may feel that should be stored with the user object, but don’t want to go through the trouble of migrating the database (and incurring possible downtime) when deploying changes to user preference structure.

Enter hstore. With this extension active and in use, the user could simply define changes to the structure without a migration and redeploy to pick up changes immediately. That API could throw whatever it wants because the JSON can be received and it can be pushed into hstore. In order to handle the myriad of user preferences, only the stuff that differs from the defaults has to be stored as key/value pair. It can be changed at will by just committing new code.<ref>https://blog.engineyard.com/2013/using-postgresql-hstore-in-a-rails-application-on-engine-yard-cloud</ref>

=='''hstore Datatype'''==
===hstore Representation===

The text representation of an hstore, used for input and output, includes zero or more key => value pairs separated by commas. Some examples:

<pre>
k => v
foo => bar, baz => whatever
"1-a" => "anything at all"
</pre>

The order of the pairs is not significant (and may not be reproduced on output). Whitespace between pairs or around the => sign is ignored. Double-quote keys and values that include whitespace, commas, =s or >s. To include a double quote or a backslash in a key or value, escape it with a backslash.

Each key in an hstore is unique. If you declare an hstore with duplicate keys, only one will be stored in the hstore and there is no guarantee as to which will be kept:

<pre>
SELECT 'a=>1,a=>2'::hstore;
hstore
----------
"a"=>"1"
</pre>

A value (but not a key) can be an SQL NULL. For example:

<pre>
key => NULL
</pre>

===hstore Operators===

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Hstoretable.png]]</div>

===hstore Functions===

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:hstoreScreen.png]]</div>

===Indexes===

hstore has GiST and GIN index support for the @>, ?, ?& and ?| operators. For example:

<pre>

CREATE INDEX hidx ON testhstore USING GIST (h);
CREATE INDEX hidx ON testhstore USING GIN (h);

</pre>

hstore also supports btree or hash indexes for the = operator. This allows hstore columns to be declared UNIQUE, or to be used in GROUP BY, ORDER BY or DISTINCT expressions. The sort ordering for hstore values is not particularly useful, but these indexes may be useful for equivalence lookups. Create indexes for = comparisons as follows:

<pre>

CREATE INDEX hidx ON testhstore USING BTREE (h);
CREATE INDEX hidx ON testhstore USING HASH (h);

</pre>

Add a key, or update an existing key with a new value:

===Other Operations===

<pre>
UPDATE tab SET h = h || ('c' => '3');
</pre>

Delete a key:
<pre>
UPDATE tab SET h = delete(h, 'k1');
</pre>

Convert a record to an hstore:
<pre>
CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');

SELECT hstore(t) FROM test AS t;

hstore
---------------------------------------------
"col1"=>"123", "col2"=>"foo", "col3"=>"bar" (1 row)
</pre>

Convert an hstore to a predefined record type:
<pre>
CREATE TABLE test (col1 integer, col2 text, col3 text);

SELECT * FROM populate_record(null::test,
'"col1"=>"456", "col2"=>"zzz"');
col1 | col2 | col3
------+------+------
456 | zzz | (1 row)
</pre>

Modify an existing record using the values from an hstore:

<pre>
CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');

SELECT (r).* FROM (SELECT t #= '"col3"=>"baz"' AS r FROM test t) s;
col1 | col2 | col3
------+------+------
123 | foo | baz (1 row)
</pre>

=='''Using Hstore with Rails 4'''==
===Install GEM<ref>https://github.com/diogob/activerecord-postgres-hstore</ref>===

*hstore is a PostgreSQL contrib type.
*Add the following to the Gemfile:
**gem 'activerecord-postgres-hstore'
*And run the bundler:
**bundle install

===Migrate===

*A migration has to be created that adds hstore support for the PostgreSQL database:
**rails g hstore:setup
*Run rake db:migrate
*Now database tables can be created using the hstore type.

===Enable hstore Extension===

First, the hstore extension has to be enabled in the PostgreSQL database. This can be done with a migration.

<pre>
class AddHstore < ActiveRecord::Migration
def up
enable_extension :hstore
end

def down
disable_extension :hstore
end
end
</pre>

===Add hstore Column===
Next, since hstore is now a natively recognized datatype in Rails, a hstore column can be added to any existing model. A "settings" column to a users table can be added as follows.

<pre>
class AddSettingsToUser < ActiveRecord::Migration
def up
add_column :users, :settings, :hstore
end

def down
remove_column :users, :settings
end
end
</pre>

===Define Accessor===
Accessors can be defined for the hstore keys in the model. Validations work just like they would for any other column in your model.

<pre>
class User < ActiveRecord::Base
# setup hstore
store_accessor :settings, :favorite_color, :time_zone

# can even run typical validations on hstore fields
validates :favorite_color,
inclusion: { in: %w{blue, gold, red} }

validates_inclusion_of :time_zone,
in: ActiveSupport::TimeZone.zones_map { |m| m.name },
message: 'is not a valid Time Zone'

end
</pre>

===A Pitfall===
One thing to look out for is storing booleans in hstore. hstore converts booleans to strings. A quick solution to this is overwriting the getter method to convert them back to a boolean on read. Following is an example:

<pre>
# convert string to boolean. hstore only stores strings
def name_of_some_hstore_key
return (super == 'true') if %w{true false}.include? super
super
end
</pre>

=='''Hstore vs JSON'''==
Hstore is often compared to JSON. Which one has to be used for what kind of application? If JSON is already being used and the user simply wants to store it in the database then JSON datatype is often the correct pick. However, if the user is looking for flexibility with the data model then hstore is likely the a better path. hstore gives great flexibility as well as a good ability to query data with high performance.<ref>https://mikecoutermarsh.com/using-hstore-with-rails-4/</ref>

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:newcomp.png]]</div>

==<b>Conclusion</b>==
An ideal use case for hstore would be when the user is not aware of the schema changes in advance, needs more flexibility and doesn't want to make frequent migrations. In case of Rails, the hstore extension enables the users to modify the Models on the fly by adding additional columns. hstore is easy to add to Rails as an extension and it allows quick database accesses too. Providing hstore extension to Rails surely makes the life of app developers easier. Also, since hstore is storing the keys and values natively in Postgres, queries run much much faster and these features can be leveraged by Rails developers to build fast and reliable applications.

=='''References'''==

<references/>

=='''Useful Links for Further Details'''==
[https://blog.interlinked.org/tutorials/postgresql.html The Most Amazing PostgreSQL Database]

[https://www.devmynd.com/blog/2013-3-single-table-inheritance-hstore-lovely-combination Single Table Inheritance and hstore]

[http://blog.remarkablelabs.com/2012/12/a-love-affair-with-postgresql-rails-4-countdown-to-2013 Hstore in Rails 4]

[https://blog.heroku.com/archives/2012/3/14/introducing_keyvalue_data_storage_in_heroku_postgres Key value data storage in Heroku Postgres]

[http://www.schneems.com/post/19298469372/you-got-nosql-in-my-postgres-using-hstore-in-rails/ NoSQL in postgres using hstore]

[http://www.youlikeprogramming.com/2011/11/working-with-the-hstore-data-type-in-postgresql-9-0/ Working with the hstore data type in PostgreSQL]

[http://www.texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb PostgreSQL (incl. hstore and JSON) vs MongoDB]

[http://www.infoq.com/news/2013/11/Nested-Hstore Reintroducing Hstore for PostgreSQL]

[http://sql-info.de/postgresql/notes/hstore-datatype-practical-example.html A practical use for the HSTORE datatype]

[http://thebuild.com/blog/2013/07/03/json-vs-hstore-which-will-get-you-into-a-cool-bar-in-the-mission/ JSON vs hstore]

[http://www.pgcon.org/2014/schedule/attachments/313_xml-hstore-json.pdf XML, hstore and JSON]

[https://blog.engineyard.com/2013/on-the-state-of-hstore On the state of HStore]

[http://www.sai.msu.su/~megera/postgres/talks/hstore-pgcon-2013.pdf Nested hstore with arrays support]

[http://charlesleifer.com/blog/postgresql-hstore-json-data-type-and-arrays-with-peewee-orm/ Postgresql HStore, JSON data-type and Arrays]

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:38:17Z

Wli29: /* Background */

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />

=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:35:48Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />
=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Variation'''==
A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
<br/>
<ul>
<li>First the build goes to A1—a small set of production boxes to which only employees are routed.</li>
<li>If the A1 deployment looks good, the build goes to A2, a "couple of thousand" boxes to which only a small percentage of users are routed.</li>
<li> A1 and A2 are like canaries in a coal mine—if a problem is discovered at these stages, the build goes no further. Only when no problems occur is the build promoted to A</li>
</ul>

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:31:37Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />
=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.
<br/>
===Database Migration===
Database changes can also be rolled out incrementally. Even organizations like Flickr, which deploy multiple times a day, don't roll out database changes that frequently. Instead, they use the expand/contract pattern. The rule<ref>http://www.informit.com/articles/article.aspx?p=1833567</ref> is that you never change existing objects all at once. Instead, divide the changes into reversible steps:
<ul>
<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If you need to roll back at this point, you can do so without having to roll back the database changes.</li>
<li>Finally, once the new version of the app is stable and you're sure you won't need to roll back, apply the contract script to finish migrating any old data and remove any old objects. </li>
</ul>
<br/>

Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:17:30Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />
=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time</pre>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp</pre>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time</pre>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time</pre>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.

<br/>
Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-09T00:16:24Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

=='''Background'''==
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />
=='''Advantages'''==
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

=='''Challenges'''==
===Redirection===
Conceptually, blue-green deployments are simple and the benefits are significant (deploy often, never go down, roll back with ease). But without the right infrastructure, they can be tricky to implement. For example, to accomplish the critical fourth step of “flipping the switch”, you need a fast, reliable, and automated means of mapping and unmapping production URLs between the blue and green environments. A DNS-based approach fails on most or all of these criteria.
<br/>
Cloud Foundry Router<ref>http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/blue-green.html</ref> is one of the possible solutions for the mapping and unmapping service request with application instance. Following shows how to use CF Router to implement blue green deployment.
<pre>cf push Blue -n demo-time<pre/>
Push the app. Router sends all the traffic to blue, the current working environment.
<pre>cf push Green -n demo-time-temp<pre/>
Now, some changes has been made and push the updated application to green environment.
<pre>cf map-route Green example.com -n demo-time<pre/>
Map the original URL to green environment. Router starts to load balance between blue and green.
<pre>cf unmap-route Blue example.com -n demo-time<pre/>
Once green environment is ready, router unmaps the blue environment. Now all the URLs are directed to green.

<br/>
Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

=='''Conclusion'''==
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.
<br/>
=='''References'''==

<references/>

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-08T23:56:31Z

Wli29:

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-08T19:54:22Z

Wli29:

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-08T19:54:06Z

Wli29:

CSC/ECE 517 Spring 2015/ch1a 4 RW

2015-02-08T19:51:37Z

Wli29:

<font size="5"><b>Blue-Green Deployment</b></font>
='''Blue-Green Deployment'''=

Blue-Green deployment is a technique used to reduce risk and delay in continuous integration. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router to this copy and make it production. In case of any error in system after this step, we can roll back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation in case of error in production to last successful build.

__TOC__

===Background===
Software applications are becoming more and more complex nowadays. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced time for release of new piece of code. With application changes going into production at such a remarkable frequency, a need was felt to automate production deployment. More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time". On an average, Amazon is pushing changes to production every 11.6 seconds. Google and Facebook are releasing frequent changes to production.
Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.
<br/>
Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.
<br />
<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:Blue_green_deployments.png]]</div>
Green environment is used to deploy all the new updates and tested. After successful testing, router can be configured to route all the new requests to Green system. In case of any error in Green system, instead of using usual roll back mechanism, we can just point router to Blue system. There are few database consistency issues involved in such methods. There is a time delay between the moment, Green copy was generated from Blue system and the moment when Green was made live. Any change that took place on Blue system during this interval must be replicated on Green system. For database applications, this can achieved using modification scripts.
Similarly, in case of error in Green system after making it live, we have to use modification scripts to bring consistency between Blue database an Green database. This process can not be completed without loosing information, if new features include database schema changes. Since database schema of Blue system and Green system differs, transferring new database changes may take a lot of time and it requires use of a complex and rigorous design.
<br />
Both these issues can be handled to a greater extent by making each system read-only during transition phase. Just before Blue environment is copied to Green, Blue can be made read only. Application can be up and running while certain/all write features can be blocked. After Green environment is tested for production and made live, we can keep it read only for a fixed amount of time. If any error occurs during this phase, then for roll back, all we have to do is point router to Blue environment and debug Green environment for error.
<br />
===Advantages===
Two basic necessities of a smooth production deployment is:
<ul>
<li>Nearly zero downtime</li>
<li>In case of error, immediate roll back from new version to older version</li>
</ul>
<br/>
By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

===Disadvantage===
Though Blue-Green deployment offers a nearly zero downtime solution for many applications which require continuous delivery and no downtime. In domains such as Banking, Retail and Social Networking, application downtime is unacceptable. Blue-Green deployment offers an acceptable solution but with a Read-Only constraint on database.
<br/>
Space and computing requirements associated with Blue-Green deployment is a big discouraging factor. Maintaining two identical production environment requires a lot of resource. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environment. Virtual machines can be used to maintain two separate identical environments. Lot of applications have huge databases and keeping two copies of databases during application deployment is a big financial commitment.

===Conclusion===
In the agile software development world, where continuous delivery is increasing becoming a necessity, Blue-Green deployment provides a solution with almost zero downtime. The performance provided by this methodology requires a huge financial commitment. Maintaining two separate production environment is a big investment. But in application domains, where continuous delivery and zero downtime is a necessity, this methodology should be used to achieve better results.

CSC/ECE 517 Spring 2015

2015-01-30T21:23:49Z

Wli29:

*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 TZ]]

CSC/ECE 517 Spring 2015

2015-01-30T21:23:30Z

Wli29:

*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 TZ11]]