Back To The Top

Application Lifecycle Management - Release management

April 15, 2021
5 min read

In this series of articles, I’m going to address Application Lifecycle Management (ALM) as a process, giving a high level overview of the subject for novices and some useful insights for the more experienced out there.

Why Application Lifecycle Management (ALM) is necessary.


Technology is rapidly pervading every organization in the world. As more and more companies become digital companies, it’s the applications and services, that give them a competitive advantage in the marketplace. Thefore it becomes critical that the development, testing, deployment and maintenance of these applications are completed in such a way that not only meets the business obectives but is also as effecient as possible and constantly improving through feedback loops.

Take too long to develop new functionality and a competitor will steal your business. Don’t test enough, or effectively, and you’ll face issues in your production environment that will be costly to resolve. Don’t deploy your applications into production considering all the factors at play and you’ll find yourself repeating the activity, rolling back or worse pushing code to production and breaking functionality, or integrations, that already function. Once your ERP or CRM soluton is in production it can’t remain static, you need to constantly improve. Monitoring and maintenance become critical for giving information back and making changes that improve your product, service or business process. This is what will allow you to compete in a crowded marketplace.


What is ALM.

Well the clue is in the same but what we are interested in is how we manage the actual activities that occur throughout the lifecycle of an enterprise application like SAP or SalesForce.

The topics this series aims to cover are:

  • Release Management
  • Test Management
  • Test Scope for ERP’s
  • Application Lifecycle Management Process
  • Change Management
  • Testing
    - Test Process
    - Test Phases
    - Regression Test Process
    - Defect Management Process
  • Cutover Process
  • Move To Production

Release Management

The first topic of this series is Release Management. So why do we need to think about Release Management? These days more and more customers cannot afford for their production environments to be out of commission for even 1 minute. As technology becomes ubiquitous and competitive advantage is gained through more efficient and effective enterprise systems it’s critical that customers protect the health and integrity of their production environments, and services, through the use of a series of formal procedures and checks.

So then the goal of Release Management is to take a holistic view of a change to an IT product, or service, and ensure that all aspects of a release, both technical and functional, are taken into consideration when moving code to production.

However, change to an IT landscape introduces risk and risk must be controlled and this is where we introduce process to control the changes.

Typically, the business wants to release more functionality more frequently and the Release Management team’s job is to schedule and execute these releases while mitigating the risk of failure. This must be done by providing guidance and visibility towards management around the risk of releasing functionality and from a process perspective by implementing Quality Gates that aim to ensure no bad code gets shipped to production. You can think of a quality gate as a milestone that determines whether changes can released to the next environment. Only after a quality gate has passed can the release continue.


Typical Release Phases

  1. Scope.
    This where business and IT must come to a common understanding of what is required and what is possible. The business must state what they need, the development team must understand the business requirements and any dependencies then the architect must envisage how the solution will be created.


  1. Build.
    This is where the development team develop the solution. For the release manager the focus is on which changes will be incorporated into the release.


  1. Test.
    During testing the scope of the release is testing for functional and technical correctness before being released.  This includes Integration, Acceptance, Regression and Performance Testing. Tools like Qualibrate are ideal for automating these processes. Defects must be managed within the testing timelines.


  1. Deploy.
    The deploy phase includes actual technical cutover of the entire release into the production environment. This means all code will be shipped to the production environment.


  1. Hypercare .
    If your implementing a major release on a mission critical system you may have a phase called “Hypercare”. Shortly after a go-live, the number of incidents typically increases significantly. This could be due to new functionality implemented incorrectly, wrong, or incomplete documentation or defects which have not been detected and solved before due to lack of thorough testing. During hypercare, which is typically a couple of weeks, the project remains focused on this release.


  1. Operate.
    The release will be formally handed over from the Development Team to the Operations Team, which ensure production support.


DevOps

But what about DevOps I hear you say. Making high speed changes to environment can be risky considering the complexity and importance of ERP sytems like SAP but if companies are going to remain competitive they need to adopt modern development techniques that can afford them speed, automation and stability. So of course DevOps is critical but this article is descibring the steps within the Release Management process and if you can automate as much as possible then all the better.

Throughout this process, stakeholders are usually engaged through go live meetings where debate is had on the benefit of releasing new functionality compared to the risk.

Release Management Teams require a good understanding of the entire project. Planning releases means understanding, and taking into consideration, the overall activities executed throughout the release (analysis, design, build, tests, documentation, knowledge transfer, implementation, early live support).

Release Management teams must also be the bridge between functional, technical, testing, change, business and management teams and are often.

Release Managers are the jack of all trades.

Ready to get started?
Contact Us
Close form
Contact Us
Close form
Challenging projects need tailored approaches
Tell us about your project. Share your challenges and concerns, and we’ll schedule a call to provide a tailored solution.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.