6 best practices for application deployments

Many software development teams are now working in Agile/Scrum way and that’s great! One of the cornerstones of Agile way of working is “Deliver value fast and often”. Real value is delivered only when software is running in production (not Dev, not QA J).

Having right deployment principles and practices in place is all the more important in Agile environments because new increments are produced by scrum teams at the end of each sprint. A right deployment strategy is a key factor to have faster and effective feedback loops from each environment. Below are some of the best practices for application deployments.

Build once deploy anywhere

Do you run into situations such as “Hey! It works on QA but not UAT or Prod”.  One of the root cause of such situations is creating build artifacts for each environment. It is key to promote same package which was tested in lower environments (Dev/QA) to later environments (UAT/Prod). You will introduce unwanted risk if you build codebase everytime to deploy to different environments as there is always a hidden danger of introducing unwanted changes. Automated deployments are very effective only when a same deployment package goes through different quality gates. If you change/ build deployment package for each environment, you are bypassing lower environment quality gates.

Hint: Use same build package and promote it through all environments.

It should be a people first process

Using right tools for application deployments is important. However, focusing on tools alone will not help.  Deployments are smooth when there is a better collaboration between people who build the software and people who deploy the software. When work is done in silos, focus is narrowed which leads to expensive and time consuming handoffs.  Improving the speed of the slowest member of a convoy increase the speed of whole convoy. In the same way, having better collaboration and elimination of waste during handover improves over deployment process.

Hint: Improve collaboration between Dev and Ops to minimize handovers.

Make deployments boring

Deploying to production need not to be a ceremony. Production deployments need to be routine, boring events because same process is used all along for each environment. New features you deploy to production should give you excitement but not the deployment process J. You will add unnecessary complexity if you customize deployment process for each environment.

Hint: Use same repeatable and reliable way of deployments to each environments.

Automate, automate, automate

Automate your build process, automate your application/component configuration (configuration as code), automate your infrastructure (infrastructure as code), automate your deployment process. A good rule of thumb: “Everything that does not require human judgment/intervention is a candidate for automation”

Hint: Visualize your current end to end deployment process and identify quick wins and low hanging fruits to automation or to identify bottlenecks

The Architecture Drives the Build

Batch size has great deal of influence on flow and architecture influences batch size. If you modify or add one line of code, how big is the impact on testing, building and deploying the package? Follow standard design principles such as separation of concerns, Single Responsibility principle, Principle of Least Knowledge, Don’t repeat yourself and minimizing upfront design. As depicted below, if you have a spaghetti architecture deploying a change is expensive and time consuming, so choose Ravioli 😉

archi

Hint: Choose a loosely couple architecture and focus continuously on architecture refactoring

Manage your dependencies

One of the key challenge working in distributed, multi team environment is dependency management. There is a high need to ensure easy distribution of artifacts produced by different teams as they share dependencies between them. Using a repository manager comes in handy in this situation. It is also useful to define access rules for users and groups that consume artifacts so the consumer uses right artifacts/version.  Other benefits of using a repository manager includes reduction of build time as significantly reduced number of downloads off remote repositories. You can also use a repository manager in case you want to roll back to a previous version.

Hint: Always use repository manager to manage your dependencies and version control your build artifacts.

 

Advertisements

Who can be a great scrum master?

Lot of organizations, managers and scrum masters have this question. What makes a scrum master great? Is he/she just need to know scrum or do they need to have more than that?

My usual answer – a scrum master need to have some skills and traits. Of course, having sound agile/ scrum knowledge is important and equally important is some mindset aspects which are listed below.

  • Don’t ask for permission, ask for forgiveness
  • Ask the team
  • “I have great responsibility, but no authority”
  • “The collective minds of the team vastly exceeds my own”
  • My job is to make sure I’m not needed
  • I win when the team wins
  • Able to holding the mirror for them to reflect and adapt
  • Make team feel accountable, inspired, focused
  • Inspire, don’t “require”
  • Don’t give team the fish, teach them to fish.
  • Non judgmental
  • Actions based on facts and not on perceptions
  • You are a midwife, not the laboring woman Smile
  • Live the values!
  • Have serve the team as primary goal.

Myths about Scrum, Agile, Software development

 

During past few years, my role as a scrum.org trainer, agile coach, software developer has given me opportunities to interact with some of the best and brightest of the industry. At the same time I’ve also interacted with some people, teams and organizations which somehow got into the trap of believing some myths of our industry. The below list is based on what me and my colleagues at scrum.org have seen.

Scrum:

  • Scrum is the silver bullet that can make any project finish on time.
  • Scrum can put your project to failure.
  • Scrum should be changed to fit your company. (Note: Scrum is a framework, it can be adapted but no changes it its core essence)
  • Product Owner can accept or reject increment.
  • Scrum is suitable only for small projects.
  • Scrum does not work for remote teams
  • Scrum only works for mature team members
  • Kanban is more flexible than Scrum
  • Scrum does not work for fixed price projects
  • Tester does not have any role in Scrum
  • Scrum Master is a project manager in Scrum
  • Scrum (or any part of it) will never work here
  • Our project/product is different. Scrum is no good use here.
  • Scrum doesn’t work when there are too many dependencies between teams
  • Scrum can’t work if you don’t change performance appraisals, incentives, etc
  • Scrum doesn’t work if your software runs on hardware
  • One PO cannot possible handle X teams  (where x is some number larger than 2-3)
  • Scrum can’t/shouldn’t be used for ‘maintenance teams’ / Kanban should be used for maintenance/brownfield/legacy teams
  • Scrum is just Waterfall done more often

Agile:

  • Agile teams don’t do any planning
  • Agile teams don’t do documentation
  • Agile teams are cowboys where you don’t have any control over them
  • Pair Programming is someone watching over my shoulder
  • If we skip documentation, we are Agile
  • Agile ignores risk
  • Agile doesn’t believe in any metrics
  • Agile requires no management
  • Agile requires no experts
  • Agile means no deadlines

Software Development:

  • Bugs/Production emergencies are always going to happen
  • Test Automation is too expensive and too hard to be worthwhile
  • We have to be able to fix schedule/scope/cost to keep customers happy
  • Adding people to a project that is running late will get it back on schedule
  • Developers can’t talk to customers
  • We don’t have any way of getting customer feedback
  • Schedule, Scope, Cost is a great measure of software success
  • We’re doing Scrum, so we don’t need to do TDD and Pair coding
  • Programmers cant be trusted to test their own software
  • Only the testers do testing.  Testing is not my(programmer/analyst/architect) job
  • The architecture/design must be done upfront
  • Only the BA writes requirements.  Requirements are not my(programmer/tester/architect) job

Continues Delivery with Release Management – Introduction

 

Microsoft recently acquired InCycle’s “InRelease” software [now called as Release Management (RM)] and integrated with VS 2013.  Release Management software fully supports TFS 2010, 2012 and 2013.

Before we look into details of Release Management, let’s look at what Continuous Delivery means.

What is CD?

Continuous Delivery is the capability of automatic deployment of components to various servers in different environments.  This typically involves configuration management of different environments, ability to define and customize a deployment workflow driven by business involving multiple roles in organization.

Why do we need it?

Well, DevOps is the talk of the town. If you want to be a cool kid (team), you gotta know/implement CD. Apart from the cool factor, CD brings following advantages to the dev team and business.

–          Develop and deploy quality applications at a faster pace.

–          Improve value of deliver by reducing cycle time.

–          Enable same deployment package to traverse various environments as opposed to rebuild for each environment

–          Manage all configuration information in a centralized location.

–          Have repeatable, visible and more efficient releases

–          Alight with deployments with business process

–          Adhere to any regulatory requirements during deployment process.

What is Release Management?

Release Management is a continuous delivery solution for .NET teams for automating deployments through every environment from Team Foundation Server (TFS) until production. RM also allows to define release paths to include approvals from Business and other departments (such as ops) when required. RM enables to assemble all the components of your application, copy them to required target servers and installs all of them in one transaction. QA checks such as automated tests or data generation scripts, configuration changes etc. are all handled by RM. Release Management also handles roll back in required scenarios.

Release Management Components:

The following diagram shows the main components of Release Management.

Release Management Components

Client: There are two Client components. The Windows client is a Windows Presentation Foundation (WPF) application that serves as the main interface point to manage release information.The Web client is used to act on Approval Requests. This is the interface to which users are directed when following links in e-mail notifications. Client is used both by business and development teams to provide necessary approval when required.

RM Server: The Server component is the heart of Release Management. It is a combination of Web and Windows Services that expose contracts used by all other components. The server component also contains a SQL Server database. Typically, RM server is installed on TFS server and can share same SQL server.

RM Deployer: The Deployer component is a Windows service that lives on the Target Servers (such as Dev, QA, Prod etc) where your application components need to be installed.

Tools: The Tools are components that help in the deployment of various components to different servers, configurations etc. Few of the are given below.

–          Installing a version of a component to a specific environment.

–          Deployments to Azure

–          Uninstalling a previous version of a component before a re-deployment

–          Deploying reports to Microsoft SQL Reporting Services

–          Running SQL scripts on a database server etc.

In next blog, I’ll write about configuring Release Management.

Reference material:

Channel 9 Video

Visual Studio 2013 ALM VM – Hands on lab

InRelease User guide

Continues Delivery with Release Management – Configuration

This blog is in continuation to my previous blog about introduction Release Management tool to implement continues deliver.

Release Management software (server, client and deployment agent), installation guide, user guide can be downloaded from here.

1. Server can be installed on TFS server and RM can create database on the DB same server.

2. By default, RM runs on port 1000, but can easily be changed.

3. Server configuration is pretty straightforward, deployment agent can be configured in the Client by choosing Administration, Settings, Deployer Settings

image

4. Most of the key configurations such as TFS user groups, SMTP settings, connections, servers etc are configured via “Configuration Paths” This can be done by navigating to Administration, Settings, System Settings.

 

image

In next blog we will see how to create and configure release pipelines.