Software development simplified – Deployment, what have we done?!

So now that we’ve spent several weeks to months on gathering the requirements -understanding the needs, came up with the best possible design, have had several touchpoints and reviews, moved to development, have extensive testing done, we are ready to deliver the solution.

Most often this is referred to as deployment of go live. It includes all the activities to make the solution available to the public or the intended end-users.

This can be both a very exciting and very stressful time. There are a lot of efforts going into deployment and the planning of it.

But how is it done really?

The activity of deploying a solution is comprised of several different steps. Just like a surgeon in the operating room before closing - making sure nothing is left in the patient’s body, a checklist is often used to ensure everything is in check.

Such a checklist will contain items such as:

• Go/No Go – held with all stakeholders

• Pre-deployment walkthrough

• Setup or update server environment

• Schedule maintenance window

• Lockdown application (for already existing)

• Back up existing system (database and application)

• Install new updates on the servers

• Perform validation testing

• Fix defects found (if any)

• Re-install and test again

This is a summarized list. Depending on the size and nature of the application, this can be an extensive list, especially if several stakeholders are involved.

What if it doesn’t work?

There are times where when installing an application to a different environment than the one on which it has been developed and tested may lead to several major issues.

If this happens, the Project Manager, along with inputs from its team, must decide if they are concluding the deployment as is, or if they are to pull back.

To leave a deployment in with major issues is not the recommended approach. However there could be time where the application is not mission-critical and the client is comfortable with having some defects, with the knowledge they will be fixed and resolved shortly thereafter.

Most times, the team will pull out. This means, the team will take the appropriate steps to revert back to the version previously installed on the server. This is what a backup before starting any activity is critical.

Now what?

So the application is in with minimal challenges. It accessible to the intended audience. What happens next?

First if this is a net-new application, a training is to be delivered also. Unless there is a dedicated training function within the team, this has to be performed by members of the team that have been closely involved. Most times a Business Analyst or Testing Analyst, or a combination of both, will take on this task.

As they were both involved (or should’ve been) from the initial stages of the project, they are to know the ins and outs of the solutions. Providing them a good point of view to deliver a training session to the end-users.

Once a training done, then becomes what some call, a warranty period. This is a period during which defects, if found, will be reported and fixed. This is good practice to offer because although you may have the best of teams, it is only until the application is used by the target audience in the run of their daily operations that you may only discover certain things that even the strongest testing techniques would not have picked up.

Once the warranty period over and the client is fully utilizing the application delivered, only then can we say our job is done.

Brenda Bossé Business Unit Manager - Software Development

Missing Link Technologies Ltd.