Software Release and Deployment – Everything You Need to Know!

We have already discussed the Version Control Systems which is a key to SCM, then Build Process which is a next step of development and now we will discuss about the Software Release and Deployment process which publishes the actual software for the end users who can view the product on web.

I know you are thinking – why am I clubbing these two topics (Software Release and Software Deployment) in one article! 🙂

Basically, there is a strange reason behind this – when I started my career as SCM team member, I was being told that software release and deployment are the same, which I kept hearing from several individuals. Some people know about both of them but tend to club them together every time.

It isn’t true – both software release and deployment are different. Although the software deployment is one of the activity of software release process but its never the same.

Let me explain in simple words!

Software Release is the process of performing all the activities which makes a new version of program available to the end users.

This includes requirement analysis, developing the code, creating the build, deploying on target environment and signing off after the end to end Testing.

Whereas,

Software Deployment is the process of deploying the software build on the target server(s) which includes installing, updating, un-installing, distributing software applications where applicable.

Software Release and Software Deployment

So, let’s first discuss about Software Release process.

Basically, the release consists of a number of problem fixes and enhancements to the service. It may contain a new functionality or change in existing functionality.

All the release changes are managed by a release manager who is responsible to get the changes approved by all the relevant stockholders as per scheduled plan.

There are several Types of Software Releases, some organizations follow most of them, some follow a few.

Releases are often divided into:
„
Major software releases: These releases contain a bulk of new functionalities, most of them may make intervening fixes to problems redundant. A major upgrade or release usually overrule all the preceding minor upgrades, releases and emergency fixes.

Minor software releases: These releases contains small enhancements and fixes, few of them may have already been issued as emergency fixes. These are installed on top of major releases to provide larger scale point release updates.

Emergency fixes: These releases normally contain corrections to a small number of known problems which are actually affecting the business and can be or need to be fixed quickly.

Maintenance Release: Incremental update between service packs or software versions to fix multiple outstanding issues.

Patch: Patch is released to fix a known bug/issue, a specific software failure and it is applied as ad-hoc as soon it is available

Hotfix: Hotfix is to fix a very specific issue, specific customer-reported software failure. It is similar to Emergency release.

Service Pack: This is used to do the large update that fixes many outstanding issues, normally includes all Patches, Hotfixes, Maintenance releases that introduce the service pack.

Daily Build Releases: A daily build is really for those people who really wants to risk the project and ready to face the challenges.

Usually these releases are not tested and could represent work in progress that sometimes means not working at all.

However, big organizations who can afford the man power do rely on daily build releases as they need to issue a new change/fix/enhancement every day.

I think I have talked enough about target environments and I’ll write about them in my next article.

Software Release and Software Deployment Process

Moving further with Software Deployment Activities

Software deployment may consists of several activities based on the requirement and your system structure.

Basically, deployment means to deploy the specific build along with all the dependencies and perform the specified activities, such as:

Deactivate and Uninstall: In order to make a new program available, you may need to uninstall the old software/program after deactivating it.

Its actually shutting down the specified component and removing it from the system

Install and Activate: Once you have uninstalled the defined system component, you need to install the new software/program followed by activating it (starting the service or specified component).

Adapt: This is a process to modify or reconfigure a software system that has been already installed.
Update: The update process simply replaces an earlier version of all or part of a software system with a newer release.

Retire: Once the software reaches its end of life cycle, it is marked as obsolete and taken out from the system.

Logging: A log for all the activities should be captured and archived in the deployment server, It would be useful for future and for investigation in case of any error/issue.

Notification: This would be the last task of the deployment process. Its a good practice to inform all the team members who are working on the project about the deployment status.

Now that we have started talking about software deployment process, it would be incomplete if we do not discuss about the Software Deployment Tools .

There are plenty of software deployment tools available in the market.

As I always say, it’s purely a team call which tool they prefer because all the tools have their own approaches, methods, process, some pros and cons as well.

Ideally a team should do a little research with their project requirement and try to evaluate for few days with different tools to find out which tool suits their project requirement and which would be easy/simpler to use and of-course it should be in-budget and efficient as well.

Now, the question arises, if we set the deployment process and use the appropriate deployment tool if needed, how deployment will initiate?

The answer is Deployment Triggers.

Deployment can be triggered in various ways…

It totally depends on the project requirement whether you need to deploy the end to end application or just a module. Based on the requirement you can configure your deployment process and trigger the deployment.

You can schedule the deployment either for specific event or for specific time. You can also configure the upstream deployment by which whenever the build gets completed a deployment automatically gets triggered and notifies the users on completion.

However, a manual deployment trigger is most preferable way of triggering the deployment. In this way you actually can follow the deployment and alert the users accordingly.

Well, as mentioned before following manual process every time is time consuming and involves lot of human efforts, time and money.

We should always prioritize the work to automate the manual processes which will not just save efforts, time and money, it will increase the project efficiency as well.

So lets now talk about Automated Software Deployment.

In every successful organization, automating the software deployment always becomes the vague piece in software deployment life-cycle.

This ensures that the deployment process is completely repeatable and consistent which will increase the productivity.

Deployment Automation is a process to combine all the necessary deployment activities starting from fetching the correct build and performing pre & post deployment activities such as uninstalling, installing, modifying, restarting the services, etc

There is a huge risk in deploying the build and configuring the target system manually.

It’s pretty common to miss out one of the important steps in a release.

It is good if you realize early but if the fault gets deployed and broken software ends up going live then it will create a big mess and can be cause of unwanted outage.

This is why Automated Deployment has proven to be more reliable and efficient.

Its just an one-time activity and you will get the same result no matter how many times you deploy.

You need to test automated deployment carefully, if you are adding a new step or modifying any existing one.

Automated Deployment has become a cornerstone software development.

With the help of Automated deployment, a software can be released more frequently and quickly.

I hope you enjoyed reading about the Software Release and Software Deployment processes. We will continue this journey with Target environments in our next article.

Please refer the article to know more about Software Release & Deployment Best Practices

Keep enjoying…

12 thoughts on “Software Release and Deployment – Everything You Need to Know!”

  1. it’s my very first time visiting your site and I am very fascinated. Thanks for sharing and keep up 😉

  2. Very nice article, I would like to know about the issues while building, deploying the software?What are the pre-requisites while building(pre-build, build and post-build) and what are the constraints we need to check?what are the pre-requisites while deployement(pre-deploy, deploy. and post-deploy) and what are the constraints we need to check? It would be great if you help me with this….

    1. Hi Surendhra,
      Thanks for your query.

      There can be multiple issues which can occur during build/deployment process, such as compilation, runtime, environment, network connectivity, permissions issues, etc which can be simply resolved by following best practices which are listed in the article.

      Pre-requistes for builds are :
      – Version Control System and CI tool are properly integrated with required permissions.
      – Pre-hook and Post-hook are configured in VCS.
      – CI tool should detect the VCS commit either through set polling or in continuous way.
      – Appropriate build tools are configured for CI tool and on CI server.
      – Alert mechanism should be configured in CI tool.
      – CI tool should be integrated correctly with Artifact management system with required permissions.

      And Pre-requistes for deployments are :
      – The server(s) where you are deploying artefacts is up and running.
      – Your CD tool has the appropriate read/write access on the deployment servers and access to given path/location.
      – CD tool should be integrated correctly with Artifact management system with required permissions
      – Make sure you have enough storage space in the deployment servers.
      – Alert mechanism should be configured in CI tool.
      – Monitoring systems are properly configured to accompanying the deployments on the server.

      Hope that helps…

Comments are closed.

Scroll to Top
Scroll to Top