Enable your development team with Continuous Delivery Pipelines

//Enable your development team with Continuous Delivery Pipelines

Continuous Integration and Continuous Delivery are often talked about as something that always go hand in hand.  Teams often spend months and month trying to come up with the “perfect” mixture of tools and workflow so that they can finally start putting their theory into practice.  Based on my conversations with many teams, the reluctance and long (over)design process for their pipelines often fall under one of these:

  • Setting up continuous integration is really tough
  • We want to pick the perfect tool – we only get one shot
  • Our organization is not ready for continuous deployment
  • We don’t know where to get started
  • We have a very complex system that is not a good candidate for continuous integration
  • And a few others

image

I encourage people to simplify their thinking a bit and not try to do it all at once.  Although you could add tens (or hundreds) or steps and tools to your continuous delivery pipeline, let’s start with the basics and add to it if there is value.  Once you have your pipeline in place, adding new steps is not typically super challenging.

Continuous Delivery

When talking about Continuous Delivery, this is what I typically want to have as a minimum:

  • Continuous Integration Build – The moment your push your code to the server, the build starts.  This includes compile and test of our code – we want to know if we have any quality issues that are introduced with code changes
  • Release – Define environments and steps (manual and automated) that should be executed when code is ready for deployment.  This also includes approval gates (manual and automated)
  • Cloud – We like to leverage Azure as a way to quickly spin up and tear down environments and have a production-like environment where we can run validation
  • Infrastructure as Code – Code, Database, and Infrastructure moving forward together, all version-controlled. In Azure, we use ARM templates, and they live side-by-side with our code.  No resources are created in Azure manually through the portal
  • Instrumentation and Feedback – Once the application is deployed, we want to know what type of impact our changes have on our customers.  Are pages slower? Are database calls taking longer?  Can users find the new functionality that was deployed?  Are they accessing the new features the way that we expected them to?  Do we know about errors before someone calls us?

There are many tools that let you do these.  We are big believers in VSTS and Azure and we typically setup our full pipeline, from local changes to production, as soon as we start on a project.

Potentially Shippable Product

The reason why we focus so much on establishing our delivery process as early as possible is that we don’t want to fall into the trap of assuming that the number of story points delivered every sprint counts as being successful.  I’ve seen too many teams that are very happy about their high velocity and when I ask them if any of their stories are in production, the answer is no. And if I ask them if they’d be comfortable pushing out their unreleased stories to production tomorrow, the answer is a bigger NO.  Remember that your product has to actually ship, and we have to build operational code, not just code that works locally.

You cannot measure value only based on the number of story points delivered in your sprint

Ideally, your team’s dashboard includes more information than just your burndown chart and velocity.  I encourage you to have a dashboard that tells the entire picture, including your builds and releases to all of your environments:

image

Why does it matter?

Implementing an effective continuous deployment strategy enables teams to get higher ROI on their development.  A feature that has not been released loses value each day that it sits on the shelf.  These are some of the benefits of implementing continuous deployment:

  • Time to market – Reduce the cycle-time between an idea and production
  • Enable feedback loops – give your users a say in your backlog by understanding how they are using new features and quickly making changes
  • Increased quality – Your want to include automated tests as part of your CI/CD process, including Unit Tests, Integration Tests, Functional UI tests, and load tests.  Running these early and often gets your team into a mode of building quality into the process rather than waiting for another team to certify quality.
  • Reduce risk related to long release cycles – Long release cycles lead to a lot of changes going in at once. Every environmental change, code change, database change, and others increase the risk that you’ll have deployment problems and that you will negatively affect your users
  • Sustainability – A lot of developers thrive on seeing their code actually being used.  If I code something and I don’t see it being used for many months (or even years), I will become less engaged with the project and I will lose the understanding on how real users will use the software.  Developers typically don’t want to work in feature factories, but instead, they want to see the impact that their changes have on the business.

As you think about the metrics that you want to keep track of, add this one to the list:

How long does it take you to go from code commit to successfully running in production?

Cloud-first development

Many times, the driver for Cloud-first development is the ability to move faster and remove the constraints of physical infrastructure.  Having a Continuous deployment process in place from the beginning, allows you to really use the cloud as a tool that enables your agility.  You can seamlessly spin up a full environment for each of your feature branches, and when you are ready to integrate with the rest of the code base, you know how to deploy that code and the merge process becomes easier by running your Continuous Integration process and related test cases.  The cloud allows you to deploy to production and create A/B test scenarios much easier than you would be able to do so with a traditional/on-prem environment.  Once you have Infrastructure as Code and automated deployments in place, taking the next step and creating a replica of production where you can do final testing before going live becomes feasible and achievable with little effort.  The cloud is where it’s at, and you will have a much higher chance of success if you have a solid DevOps strategy as part of your move to the cloud.

We can help!

If you are getting started (or already well on your way) with your journey to Azure, let’s talk!  We want to help your organization be successful by implementing the processes and tools that will help your team collaborate and quickly deliver value to your customers.  Our cloud-first development approach to software development brings together our Azure and DevOps expertise to help you deliver quality software faster.

By |2018-05-20T19:27:57+00:00May 20th, 2018|

About the Author:

Founder and Chief Technologist at Nebbia Technology. Esteban has a passion for ALM, TFS, Azure, and software development best practices. He is a Microsoft Visual Studio ALM MVP and ALM Ranger, Pluralsight author, and the president of ONETUG (Orlando .NET User Group).