Wanted to introduce an agile architecture tip here.

People talk of agility all the while but a lot of best practices need to support agile such as all the things that devops brings to the table such as CD/CI and everything continuous. This means that there should be an ability to deploy code into production going through dev / test / pre prod / prod and everything in between that you can plan for releases in a product or solution. Unless an organization pays complete attention to getting the CI / CD practices upto date there can be no real agility as it is known the last mile in development is the place where the code gets pushed into production and there are many challenges right from developers saying the code works fine on our machines to the QA team and system test people having another opinion. Continuous development , continuous integration and continuous deployment makes all of this possible as it is quite possible to push code into production from development environments .

For agile practices like these you could use green blue deployments techniques. A little about the green blue technique

, it involves maintaining two environments one green and the blue environment where the exact production like environment is maintained end to end from the web server / app server , operating system and the database. This quite difficult to achieve end to end . So organizations make do with getting either the web server  / app server replicated and have a common database. In that case using a router in between the traffic is routed to either the blue server or the green server.

ROUTER – —-> (test.sampletrail.com) > Blue Server ( let’s say this is the main server )

ROUTER ——> Establish temporary connectivity with the Green Server ( Standby server in case the main server goes down )

When you need to divert traffic to the green which has the latest code and patches while blue has the old code and server status. The blue can still be considered as the fall back server in case the green server gives up and is not able to handle the traffic and if found unsuitable or not stable. This option gives organizations the confidence to keep the system up and running and as they say is one of the ways in which the lights can be kept on. This is most often used in many RFC and RFPs from clients

There can be many edge cases there such as while the transition is happening to the green and then back to the blue what about the transactions that get posted via the green. If the database is unified then the challenges in this not wrecking the system can be limited based on the code in the application logic. But it is implied that the design level changes are taken care, to rollback or reconcile such transaction postings by means of application logic.

When the transition is happening only read only transactions are possible to ensure there is minimum changes to the consistency of the system. You can have this setup in a virtualized setup on the same physical machine or different machines.

Always keep the option of toggling between the blue green states so that it ensures complete flexibility in trying out quite and application patches with a lot of agility.

What are such practices that you use currently or want to be updated on do let me know ?

References :
https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html
https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/
https://martinfowler.com/bliki/BlueGreenDeployment.html

Success today requires the agility and drive to constantly rethink, reinvigorate, react, and reinvent. – Bill Gates

Picture Courtesy : Cloud Foundry blog

With a backdrop of the traditional waterfall mechanisms of project management, build and release was always pushed aside as the last but one activity before cutting the CD / testing certification of the software. The last mile as it was referred to this although was the last step in the journey towards a software delivery it would remind one of the famous lines the “Journey has just begun”.

Although this was the last step supposedly to be taking 20% or less of the actual effort it generally would be the other way around , taking a significant effort and often not scoped in estimates and it was quite OK to do so till recently. Start the blame game and developers blaming QA and vice versa and everyone including the other teams would take potshots at each other and say their part worked fine but the had issues in the final integration. All of this started to be stage managed with late nights and weekends going into getting all pieces talking to each other is all very familiar with traditional methods in place.

What next ?

There are some best practices such as the following that are being followed where everything is continuous meaning

Continuous Delivery
Continuous Integration
Continuous Deployment

What all of this means in short is every time you change any part of the product the whole SWAT team runs behind the scenes to check if all is OK with the system. Now if someone were to check in something that breaks the system then it needs to be fixed then and there. Have seen that code needs to be fixed corrected by the erring developer/team by the same night. There are protocols like call the guy involved to get it right and ensure only code that is working is checked in . All of this boils down to the Agile concept of everything that is checked in is tested and fit for deployment into production post a formal QA team blessing the product. But otherwise the usual suspects are nailed down early and the QA goes on to find the more grueling aspects of the product committed features which have escaped the unit testing/TDD iterations.

If something out here still finds its way to the bug tracker then the developer needs to take care of UNIT TESTING / TDD best practices on ensuring his/her code works well under all circumstances and integrates with all the surround infrastructure and allied pieces of software. Software ownership and craftsmanship are truly enforced here as this goes in a loop till the process achieves some predictability on the process.

DevOps in a five line code snippet for starters.