Skip to main content

Upgrades - Approach and best practices


Why Upgrades

 Below is the list why companies go for the upgrades. The list is not exhaustive. However, it has all the major points.
1.     Product is not supported by the vendor due to higher version available in the market. To buy the support in the lower version, the corporates has to pay premium support fees.

2.     Enhanced Security features available in the higher version which is aligned with the IT Security policy of the corporate.

3.     New business features are added in the higher version. To be competitive in the market, corporate need to implement those new features of the application.

4.     The process has been improved in the new version

5.     The dependent product required higher version. Suppose, corporate is going to implement/upgrade a product. The recommended software for higher version of the product requires upgrade of the existing software (eg DB upgrade).

6.     There is a cost associated with the upgrade. If corporates does not want to go for the upgrade and build the features in-house, then they need to analyze the cost required to build the new features and cost of upgrade. If the cost if enhancement is much higher with high complexity, then, corporate might go for the upgrades.

Types of Upgrades

Upgrades can be classified in two parts. It is either technical upgrade or Functional+Technical upgrade.

Upgrade Strategy

Depend on the type of upgrade selected, the strategy will change. Below, different strategies are generally taken based on the upgrade type
1.     Technical Upgrade: Technical upgrades are when there are no functional changes in the application/component. For packaged solution like Ariba, the upgrade package generally comes with some functionality changes and in some cases, those are not backward compatible. In those cases, we need to follow the Techno-functional upgrade path. For upgrade of component (say Database, Websphere, JRE etc), the components are generally backward compatible. In those cases, the best approach for upgrade is Test Driven upgrade. As there are no functional changes and the upgrades are backward compatible, the Test driven upgrade will give shorter Go Live time. The recommended steps would be to break the upgrade process in different phases with definite deliverables in each of the phases.
·       Inventory collection
·       Upgrade in lower environment functionality test
·       Upgrade till UAT/QA and functional test
·       Production go Live
2.     Techno-Functional Upgrade:  In Functional (or Techno functional upgrades) the application adds new features. Generally following changes are there in functional changes
·       Changes in Screen Layout
·       Changes in data structure
·       Changes in the operational flows/processes

So, in the functional/techno-functional upgrades, the following steps are considered
a.     Gap Analysis: Identify the changes in the higher environment. The changes could be the object structure, changes in APIs, scheduling, UI flow etc. The list is not an exhaustive list but few important changes. Based on the identified gap, the upgrade consultant need to understand
                                          I.         If the existing process is breaking in the higher environment and coding effort required to fix
                                         II.         User training required based on the scope of the upgrade
                                       III.         Identify the critical changes in the process

b.     Enhancement backlog inventory collection: Collect the inventory of enhancement those are planned in future to identify if those features are already available in the enhanced version.
c.     Identify the scope of upgrade and stakeholder training: One of the most important steps is identify the scope of the upgrade. The scope identification will document the modules or parts of the applications suites are getting upgraded. Generally, gap analysis document helps to determine the scope of the upgrade.
Based on the scope is/are identified, the stakeholder training is required to familiarize with the changes and training plan is created for the end users
d.     Project Plan: Based on the scope and capacity, the project plan is created. The upgrade type (in-place upgrade where upgrade is done on the existing application/component or out-place where upgrade in done on new hardware ) is very crucial to plan the schedule.
e.     Upgrade in lower environment and Unit test/functionality test: Follow the created project plan to complete the upgrade in lower environment, unit test it, identify the bugs/issues with the upgrade, fix it and document it. The lesson learnt will help to upgrade in the subsequent environment more efficiently.
f.      Upgrade till UAT/QA: With the lesson learnt in the lower environment, the upgrade will be done much quickly in higher environment and deliver the environment for QA/UAT testing and bug fix. One the QA/UAT/Regression/Performance is done and bugs are prioritized and fixed as per the testing strategy, the application is ready for the production upgrade.
g.     User Training: End users need to be communicated about the changes in the application before the application goes to production. If possible, it is better to give them access to the lower environments to be familiarize with the changes in the application
h.     Production Go Live: The user community need to be communicated about the upgrade time and when the application will not be available for use. Generally, production go-live is schedules on weekends. Based on the matrix of go-nogo decision, production go-live is approved.

Comments

Post a Comment

Popular posts from this blog

Hybris Beanshell and Groovy script example

While doing support, we need to check some of the scenario and their result in the production server. The beanshell and groovy script comes very handy on this. Below are the few example of how I used/using it in my various project. This is very handy to test your data as well 1.        Check the log: Sometimes getting server access is very painful in the enterprise landscape. However, person joined in the project is required to work as soon as they inducted in the project. In this scenario, below groovy script is very useful.   Please note, run these in the rollback mode unless and until the otherwise is required. a.        The application is running from the container. For the POC, it was running in the tomcat server (tomcat/bin). To know the exact directory, run the below script in groovy console println "pwd".execute().text Below will be printed in the output tab /usr/sap/hybris/bin/platform/tomcat/bin ...
1 comment
Read more

SonarCube and Hybris integration

There are some issues reported for SonarCube 6.7 integration with Hybris. The recommended version is Sonar 6.4 or less. For Sonar 6.4, there is no need to build the database. Please follow the below steps to use sonarcube with Hybris. For the POC, we have used Hybris 6.4.0.2 and sonar 6.4. Sonar Cube configuration 1.        Download sonar 6.4 and install/unzip. 2.        For the POC, we have used Embedded Database (default). But multiple database is supported. Access management can also be implemented. However, for the simplicity purpose, it is not used for the POC 3.        The java properties can be set at the sonar.properties file (not used in our case). Example of the property is sonar.web.javaOpts=-Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError which can be enabled in the sonar.properties file under conf folder of the installed folder. 4.      ...
2 comments
Read more

Beanshell/Groovy example - Change Local.properties permanently using script

Sometimes we need to change some of values defined for properties key in local.properties/project.properties. There are three ways to do it Update via HAC Update Local.properties Update using beanshell/groovy script If we use the first process, after server re-start, changes will go. So, the value will remain in the system memory till the server got re-started. Here, will give an example how to change local.properties and changes remain even after rebuild. Run the below script in the HAC script tab with "commit" on. import org.apache.commons.configuration.PropertiesConfiguration; import java.io.File; import java.io.IOException; import java.net.URI; import java.net.URISyntaxException; //The new value to be stored in the key/value pair in local.properties. String changedValue = "NEW_VALUE"; //Key name in the local.properties String propertyName = "test.properties.value"; PropertiesConfiguration config = new PropertiesConfiguratio...
1 comment
Read more