Don't ignore the 'Core' in Continuous Delivery

You see, I'm a person who loves to write code, travel around the world, take nice pictures and eat!!! But nothing less than that, I also enjoy running (especially in the morning!!!, ). It's amazing to have that feeling of the fresh air, smell of the grass and sense the muscles working while observing the surroundings. My running helps me to do my job better because it helps clear my mind, relieves stress and builds a lot of confidence. Its provides me with those moments with great ideas and solutions to most of the problems you have at work or life. By the time you finish running, you have already set up the goal for the day with a certain amount of clarity about the activities that you have to do.

The more I started running, the more I loved challenging myself with those extra miles and pace. But with my overgrowing excitement, I was making the obvious mistake.. I was running too much, too soon, too fast. While doing so, I forgot about the "little things" that help stay healthy and flexible. I started getting injuries, my hips and hamstrings were always tight. I was breaking down with back pain and injuries. I knew I was doing something wrong and it was time to get an expert advice. Having heard the back pain story many times, the physio explained me about the importance of 'Core' muscles and the exercises to do that would strengthen my muscles and improve my core stability. He suggested doing squats, swimming, pull ups, crunches etc. So I decided to give my running a break and focus on core building. It felt a bit off in the gym doing all those non equipment exercises while everyone else was lifting those 20/30 kg dumbbells, but a month after training, I started noticing the difference. I felt more stronger with increased muscle mass, my posture was better, lost some body fat and I was more agile!!! I started running again and this time I noticed the difference immediately. My core helped me to maintain an efficient running form  helping with better stability, balance, posture and overall control.

In short, lesson learnt from my running experience. "Ignoring core strength in your training program may look like working for a short term, but is a recipe for long-term disaster. Lack of core-strength and flexibility causes your body to find a path of resistance towards running or cause the body to adapt in a negative fashion that will most likely lead to complex injuries!!!"

Well how does this relate to continuous delivery and DevOps? The answer is , before immediately adopting a CD tool and start working on the pipeline, you should prepare the teams and the organization with the core of continuous delivery. The core practices like version control, build automation, test automation and continuous integration increases software process agility and helps create an organizational culture and structure to fully embrace CD.

In this post, I’ll describe some of the core practices of continuous delivery  that helps delivering software feature more frequently and reliably. 

Version control everything

Putting everything in version control (source code, build scripts, test scripts and data setup, monitoring scripts etc.) This helps in keeping track and control everything. Keeping track of the changes gives the flexibility of undo or replay any changes easily in all environments including production. You can also understand who made a change and why. Version controlling also creates the first level of built-in safety net, preventing any out of process, locally made changes or manual overrides from entering the production environment. Every change a developer makes must in the source control, any failure to do so will be overridden in the next deployment if not present in the source control.

Practice TDD

TDD is a software development approach where the development of code is driven by first writing an automated test case, followed by writing the code to fulfill the test and then refactoring. With continuous delivery, it’s very important to have the tests pushed into source control along with the implementation code. This helps in ensuring that every new code pushed will be tested in the same build process. This eliminates the risk of delivering to production the code that does not meet quality requirements.

These automated tests helps identify errors in a really short period of time. These tests give developers very fast feedback when something breaks. These tests are also called change detectors. When you make a change, the tests will detect very soon if there are any problems or mistakes. With continuous delivery organizations need the have the ability to make frequent releases of their software without the risk of breaking existing features or adding new bugs. The success of the business depends on how fast it can react to changing environments and address the new improvement suggestions with assurance. Test-driven development is the methodology that makes such flexibility, maintainability, and extensibility possible.

Continuous integration

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." - Martin Fowler

Continuous integration process runs ensures that the tests are executed every time a change is pushed into source control and ensures that the new changes didn’t break any other parts of the software. Every push automatically triggers multiple tests. Then if one fails it’s much easier to identify where the error is and start working to fix it.

Automate everything

Automation is the heart of every successful continuous delivery transformation process and the single biggest enabler for CD. The success of continuous delivery lies in stable environments, consistent build and test process and happy releases. Automation can be used to make the release process more deterministic and to bridge the gap between development and production. Development teams can learn from operations the value of automation and how to create automation scripts to improve the overall process. Together the team is responsible for defining the desired state of the infrastructure and convert this to code. The degree to which your organization can achieve successful one click deployment process that can be initiated by anyone whenever needed depends on the level of automation at every stage. At the processes like code analysis, testing, environment provisioning, defect detection and prevention at all stages should be automated. Any manual tasks should be treated as technical debt and later picked up as part of the sprint and addressed.

Test automation

The key to building quality into our software is making sure we can get fast feedback on the impact of changes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Companies adopting continuous delivery should ensure that when issues are identified they can be managed and resolved quickly and definitively. The easiest and effective way to achieve this is by having an automated test suite incorporated in the release pipeline and CI process. This kind of a process where automated regression, performance and security tests are constantly executed as part of the deployment strategy helps identify issues early and deal with them before they reach the later stages of the deployment cycle/pipeline.

Monitor and measure everything

Proper and effective monitoring of the entire process and environments is important to provide crucial information that ensure service uptime and optimal performance. It's important to measure the progress of the approach to know whether teams are improving or making progress. With the support of proper data and metrics, it’s easy for teams to inspect the current way of working and come up with ideas or processes to improve the overall CD/ DevOps movement. Measuring the current capabilities and process helps teams determine the problem areas and defined focus points for making a change.

An important DevOps practice is to work with application monitoring and insights to enable full end-to-end traceability in a product to provide both operational insights and  usage understanding

Keep focus on these core practices and move forward with your continuous delivery journey!!!

“….to satisfy the customer through early and continuous delivery of valuable software” - #1 of the twelve principles behind the agile manifesto.

Continuous Delivery – Patterns for zero downtime requirements

One of the main problems teams face when practicing continuous delivery is to manage zero downtime deployments to the production environments. The goal is to deploy as soon as possible and depending on the heartbeat of the organization, this becomes a higher priority to manage active users without losing their data and sessions during a deployment process. In this post I'll share some of the ideas and approaches that are been used for achieving the goal of zero downtime deployments.

An important process for reducing risks and managing a zero deployment downtime is by following the blue-green deployment technique. In a blue-green deployment scenario, the approach is to bring up a parallel green environment and once everything is tested and ready to go, you simply switch all the traffic to the green environment and leave the blue environment idle. This also helps in easy rollback and switch to the blue environment if anything goes wrong in the current installation.

In a horizontally scaled environment, where you have multiple servers handling the load where the traffic is routed to one of the servers based on the load balancer scheduling algorithm, you can update the servers one-by-one and bring them online after the updates. The same approach will be used in this scenario also, but with the only difference that there will be N blue and N-1 green servers where N is the number of servers in each group in the web farm.

As long as deployment of application code is only considered, there is no problem managing that with a zero downtime requirement. But consider the deployment scenario which involves changes in the database schema as well. You can’t now update the DB schema first and continue using the old application code to use the new schema as it will create inconsistencies considering the code is written to work on an old DB schema. This involves taking extra precautions or considerations with updates that involve DB schema changes. When it involves database changes two approaches that helps the most are:

Strive for backward compatibility by performing schema changes that won't affect the existing code and also by ensuring that the deployed code can work with the old schema.

Some of the points to consider would be to:

• Perform schema changes in a way that won’t break existing code
• New columns added are always NULLABLE
• New columns provide a default value if it does not exist.
• Don't delete columns until none of the code uses them, or can handle their absence.
• Use triggers or similar mechanisms to populate values that are important for one deployed version of the application.
• Enforce referential integrity only when it makes sense.

Have an expansion and contraction database script:

This allows you to handle database changes that are safe to apply without breaking backward compatibility with the application code. Changes like creating new tables, adding columns or tweaking indexes etc. can be handled using the expansion scripts with a trigger or scripts that fills the default values. Once the application code is updated, you can execute the contraction script to clean up any database structure or data that is no longer needed.

You should plan to execute the expansion scripts prior to updating the application code and the contraction scripts once the application code has been updated and is in a stable state. This produces a nice benefit of decoupling database migrations from application deployments.

DevOps - Workbench deployment orchestration

DevOps Deployment Workbench offers customized XAML workflow templates that are designed to encapsulate many smaller individual deployment steps into a singular consistent workflow. Using the DevOps workbench you can create deployment Activities that offer many smaller coded XAML activities that perform distinct build or deployment tasks, such as updating of a value in an XML configuration document. All these activities can be later executed from the workbench UI to perform a deployment activity.

In this article we'll use the workbench UI to create a deployment orchestration and use this to perform a deployment activity.

• From the DevOps workbench UI, create a new Deployment Orchestration as given below.

• This creates a master deploy sequence which you can customize and extend by adding custom activities that describes your deployment process
• From the properties box, change the master deploy sequence display name to your project deployment sequence name.

• The deployment toolbox contains common deployment activities which you can use in your deployment sequence by dropping them to your activity
• To start with the sample deployment scenario, we'll add a pre check for a valid operating system before copying the assemblies to the server.
• From the toolbox, drag and drop the CheckOSName activity to the deployment sequence

• From the toolbox drag and drop the .Net application deployment activity to the sequence and provide details for source and target as given below

• Save your orchestration to the disk

• We'll now use this initial deployment sequence to deploy to a test server from the workbench UI.
• For adding a new target server connection, choose Target Servers option from the menu

• Click on Refresh to see the target servers for deployment

• Once you have configured the target servers, you can deploy the application from the workbench UI by clicking on Deploy to servers from the menu
• Choose your build, package name and target server details to deploy the application from the workbench

• Click on start to start the deployment process