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 😉


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.


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 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 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


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.



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

No programmers in Agile teams!

Yes, that’s right. Agile teams don’t need software programmers, they need software developers. I don’t mean this as some English vocabulary usage. I think the key difference is, if you ask a programmer to build some code, you will get code. If that programmer is good, you might get good, reasonably commented and reasonably efficient code which works.

If you ask a software developer to build some code, you will first get questions:) before you get a solution.

  • How does it fit in the business process? Are the requirements thought out?
  • Are you sure you understand what it will cost?
  • Who will support it? What about diagnostics and instrumentation?
  • What kind of documentation will it need?
  • How might it interact with other code?
  • What platform will it run on. Are the scalability issues?
  • How might it impact future development? How might it be enhanced in the future?

Another key difference is, programmers focus on languages, software developers focus on language characteristics. A programmer might see himself/herself as a Java programmer, C# programmer or a Ruby programmer. But a developer focuses on language characteristics such as strong or loosely typed? Object oriented or functional? Interpreted or compiled? Etc. This allows developers to quickly adapt and pick up new languages and technologies.

So, the key mantra for agile teams is to deliver high business value software with high quality. This cannot happen with programmers whose focus is just to code and ignore everything else.

Code is not always ‘THE’ solution but its ‘a’ solution.

Credit: This blog is inspired by a talk from Dan Appleman

User scripts – Intro

User scripts are a handy little concept through which we can extend / customize behavior of any web site. Before we talk what user scripts are, lets see what kind of things we can do with it

  • Always display some information like time or how much time you are spending on that website etc.
  •  Remove ads from your favorite web site such as Facebook  or any news site
  • Extend or implement some functionality on web sites you like. For e.g. download albums from facebook.
  • Do some time sensitive actions such as log into a web site as soon as its up. (handy when you have to book train tickets through IRCTC Tathkal)

So, what is a user script?  It’s a script which your browser can understand and act on it.  So how is it different from Javascript or vb script? The key difference is, all these client side scripts have to be part of a web application, where as user scripts sit on browser and gets injected into every site (or selected sites)  that you open in a browser. These scripts are loaded before any scripts are loaded on the page and hence the advantage.

These user scripts are specific to browser as they act as extensions to web browser. There are lot of browser extensions out there to manage and create user scripts such as Greasemonkeyfor firefox,  Tampermonkey

In next blog,  we will see how to use Tampermoney to create user scripts and introduce a custom behavior for a web site.

Empty glass on New years?

New Year is round the corner. It is that time of the year where all of us setout goals, make resolutions, define plans to achieve them. I believe setting goals is important as it acts as a guiding post on how our energy, time and efforts are going to put in.

Let me share a simple but a great thought I picked up from a speaker in one of the conferences I attended recently. We are always ambitions. We always focus on the things that we are yet to achieve, fix things that have gone bad, try to find and fill the gaps. In a nutshell, looking glass half empty. I don’t mean glass half empty in a negative way. It is important and required to see glass half empty so we set goals to become better at we do, how we do, both professional and personal level. At the same time, it’s important to look at glass half full.

Look back at the year and ask, “What has improved”, “What has changed”, “What I/we did exciting this year”?

I recommend to do this “Yearly Review” with your clients, family and yourself.

We all take success for granted and, forget it and focus on new challenges. Before we set out goals, acknowledge success. See glass half full before figuring out how to fill the other half.

Prove me wrong!

One of the biggest challenges for agile teams or for that matter lot of organizations is fear of conflict. This fear of conflict is a major reason why organizations fail to call right shots. In a survey conducted among US and Europe executives, 85% have acknowledged that they had issues/concerns at work that they were afraid to raise. They were afraid of conflict that would provoke, afraid that it would lead to arguments that they won’t know how to manage and loose.

Arguments are necessary; disagreements are required to drive creative solutions to problems. Well, easier said than done. How can we have these conversations more easily and more often? Organizations culture should reflect and encourage the attitude of questing, willingness to start an argument. Imagine in an agile team, if individuals are hesitant to prove others wrong, it will ultimately do bad to the team.

Developing “Prove me wrong” attitude doesn’t mean that team/organization loses team sprint. In fact, the opposite would happen; there is even more team collaboration, very little room for wrong decisions or judgments. The reason why Phd theses have such a high quality is because they have to pass “Prove me wrong” phase.

It is not enough to make things transparent and open, but as I mentioned above, the discussions and arguments around it is what makes it effective.

 Openness isn’t the end; it’s the beginning. 

Credit:This blog is inspired by the TED talk give by Margaret Heffernan – Dare to disagree

You are fat..errr! you look big.

Back in collage days, I learnt a lesson when my friend almost killed me (not literally though 🙂 ) when I responded to a question by saying “yes, you look fat”.  Recently I noticed such a scenario in a team, well it’s nothing to do being fat 🙂 but fundamentally it was same, “Giving and taking feedback”.

I believe that feedback is a gift. It always helps us grow personally and professionally. Yet, most of us have a negative perception towards it. Most of us still believe age old saying “If you don’t have anything nice to say, don’t say anything at all.”

Today’s demanding and challenging work environment calls for an imbibed culture of giving and receiving feedback. This aspect should be even more emphasized in agile teams. For example, lot of agile practices have an inbuilt framework to facilitate faster feedback such as with XP, we have CI, Pair programming, Peer reviews etc, with scrum we have retrospectives etc. Most of these feedback mechanisms are targeted at technical accepts and abstracted at team level.

In order to have hyper-productive teams, individuals should be comfortable to give feedback at an individual contribution level to acknowledge his/her achievements or to identify any growth areas.

Here are some points on giving and receiving feedback.

  1. Give your feedback as soon as possible: If you notice something done really well, don’t wait till a retrospective or some event to give a pat on back. If it is appropriate, drop an email, or post it in a bulletin board about the good work. At the same time, if you see something can be improved, or done at substandard level, let the person know ASAP.
  2. Balance your feedback: Always start your feedbacks with a positive note. It is important to mix both positives and growth areas.
  3. Be Constructive: The whole idea of giving feedback to help the other person to grow and not to criticize. So, always give your feedback in a constructive way. Be careful with the language you use. Replace words such as “but” and “however” with the word “and” when you string together your positive and negative feedback. When people hear the word “but” they immediately discount the part that came before it and only hear the negative comments.
  4. Listen: While receiving feedback, listen to the other person’s point of view. Perceptions are true at least for the ones who own it. So here it out without any justification or explanation.
  5. Reaction: If you don’t completely accept the feedback, thank the person and tell him how you are going to take that feedback. Be careful, it sometime do happen, that rather than accepting the feedback, we tend to denounce not only what is said but also those who say it.

Always remember, if someone is giving you feedback, it means they are interested in what you are doing and wants to help you to become better at it. Now, coming back to my collage days, if I had known point 3, I would have said “This dress suites you very well and I guess you look little big now” (not sure if it would have really helped) 🙂