IBM Support

What is the process to be followed to upgrade to the latest versions of IBM UrbanCode Deploy servers?

Technote (FAQ)


Question

What is the process to be followed to upgrade legacy uDeploy servers to the latest versions?

Cause

What is the process to be followed to upgrade legacy uDeploy servers to the latest versions?

Answer

Upgrading IBM UrbanCode Deploy 4.8.x to 6.1.x

 

This document contains the general activities required to upgrade IBM UrbanCode Deploy (UCD) from version 4.8.x to the 6.1.x.  The overall approach is to perform a complete upgrade in a UCD test environment to validate and refine the upgrade process prior to upgrading production to minimize impact on production users.  The test environment will also provide a  environment to perform the required security model changes prior to the production upgrade.  While this document serves as a template for upgrades, each customer should carefully structure a tailored plan to meet their specific environmental requirements.  

 

Phase 1 - Planning and Preparation

 

1.1 - Engage IBM Sales team to ensure proper licensing and software access

 

1.2 - Open a preemptive upgrade PMR with IBM support

        The PMR will serve as a place holder for any emergencies that may arise from the upgrade procedure. The IBM support team can also provided feedback on the custom plan for the customer environment and provide additional clarification as needed.   

1.3 – Review setup in current environments and design to-be architecture 

      • Review the current setup of UCD server, agents and agent relays
      • Review current security model in general
      • Review current deployment processes in general
      • Design to-be architecture and create upgrade plan
      • Identify how agents are mapped into environments (use of resource groups, consistent patterns of how components mapped to agents)
      • Ensure understanding of how security is granted to users at object level
      • Understand user / role definitions and the permissions requirements for users and roles
      • Optional: Consider configuring UCD servers for High Availability or with a cold standby as per the following:

        http://www-01.ibm.com/support/knowledgecenter/SS4GSP_6.1.1/com.ibm.udeploy.admin.doc/topics/ha_overview.html

 

1.4 – Set up Rational License servers for testing and production environments

      • Install IBM Installation Manager
      • Install Rational License Manager
      • Install Product Licenses
      • Optional: Consider configuring the license server environment for High Availability
 

1.5 – Create a new UCD environment for upgrade testing

        The goal of this process is to provide you with a testing environment that matches the production environment as closely as possible. Please refer to the following technote for instructions:

        http://www-01.ibm.com/support/docview.wss?uid=swg21694427

        Note: UCD 4.8.5 has some known with upgrading to the latest version that will need to be accounted for. Customers currently on 4.8.5 should either follow this document, upgrading the 4.8.5 server to 5.0.0.2, or contact support to obtain the appropriate patch, skipping steps 2.1 and 2.2 and for the remainder of this document replace references to 5.0.0.2 with 4.8.5.

 

 

Phase 2 - Test Environment Upgrade

 

2.1 – Upgrade clone server to 5.0.0.2

      • Run upgrade script (same as install script) to upgrade
 

2.2 – Perform basic testing to validate 5.0.0.2 upgrade

      • Install a test agent
      • Perform basic testing to make sure the server is functional based on your specific usage and the security migration page is functional
      • Report errors to IBM if any
    

2.3 – Define Initial Security Model through migration tool in the UI (Critical step)

 

2.4 – Back up 5.0.0.2 server

      • Backup database
      • Backup server file system
      • This is needed if the following steps need to be repeated from this step
 

2.5 – Upgrade from 5.0.0.2 to 6.1.x

      • Execute the upgrade script (same as install script)
      • Note: The 6.1 upgrade requires a migration of codestation files may necessitate additional short-term and/or long-term disk storage to handle the change.  See the notes at the bottom of this document for more information.
  

2.6 – Configure 6.1.x server including upgrading agents and review resource mappings

      • Connect to license server
      • Upgrade and license test agent
      • Configure "importing agents"
      • Validate resource mappings
      • Review resource mappings and hierarchy to understand changes and plan for restructuring in production 
      • Validate roles, permissions, and teams
 

2.7 – Perform testing to validate 6.1.x upgrade

      • Perform basic testing to make sure the server is functional
      • Report errors to IBM, if any
 

 

Phase 3 - Production Environment Upgrade

 

3.1 – Back up Production Server

      • Shutdown production server
      • Back up production database
      • Back up server installation directory
 

3.2 – Upgrade production server to 5.0.0.2

      • Run upgrade script (same as install script) to upgrade
 

3.3 – Perform basic testing to validate 5.0.0.2 upgrade 

      • Perform basic testing to make sure the server is functional
      • Report errors to IBM, if any
 

3.4 – Apply / Define Initial Security Model

      • If the security setup was completed and exported from the test environment, then copy the migration files onto the production server
      • This is also when you would apply any changes that had to be made to security after the final upgrade of the test environment
      • If set up was not performed prior to production, go through the process of defining basic roles, permissions, teams and team-artifacts mappings
 

3.5 – Upgrade from 5.0.0.2 to 6.1.x 

      • Execute the upgrade script (same as install script)
      • Note: Ensure that the proper disk space is available to process the CodeStation migration.
 

3.6 – Configure 6.1.x server including upgrading agents

      • Connect to license server
      • Upgrade and license existing agents
      • Configure "importing agents"
      • Validate resource mappings
      • Validate resource hierarchy - deployments should work without any reconfiguration to upgraded resource hierarchy, but the default resource structure may not be ideal long-term
      • Validate roles, permissions, and teams
 

3.7 – Perform testing to validate 6.1.x upgrade

      • Perform basic testing to make sure the server is functional
      • Report errors to IBM, if any
 

3.8 – Optional: Set up cold standby server

 

3.9 – Optional: Restructure Resource Mappings

      • Restructure resources to map to better reflect the physical or logical environment such as grouping by data center

UCD 6.1 CodeStation Respository Migration Notes

 

UCD changes the Codestation repository on disk format in version 6.1. The migration process runs while the server is online, minimizing service disruption. While the migration is running, disk usage will be higher as the old format files are copied into the new format and are not removed until migration is complete. As a rule of thumb, we say migration requires 2x disk space (the size of the old files plus the size of the new files). However, the exact relationship between the size of the new repository and the old is not as simple as that. Some repositories may use more disk space after migration. For every file with identical content, the old format stores a single copy that all component versions share. In the new format, each copy is stored separately. This was a conscious decision to increase robustness and performance, but it means the final storage requirements of the Codestation repository may be higher after migration. For example, 10 component versions that contain an identical 1MB file in the old format would use a total of 1MB to store that file; the new format would require 10MB. It is also possible that migration will use less disk space than before. For example, in our own internal UCD server, Codestation disk usage decreased by 10% after migration. There are two reasons for this. First, the old format stores metadata less efficiently and this can be a large percentage of the total disk space used by smaller component versions. Second, the old format stores every component version file as its own disk file, but the new format combines many files into a small number of larger files, usually just one. This reduces disk usage by eliminating the wasted space at the end of each file that is caused by the file size not being an exact multiple of the disk block size.

It is difficult to predict the post-migration size of any particular repository without a detailed analysis of its contents. The final size depends on which of the above factors dominates, and that depends on the content of specific component versions in the repository. Repositories with a large number of redundant, identical files may be larger after migration; those without will be a little smaller. 

Document information

More support for: IBM uDeploy
Documentation

Software version: 4.7.2, 4.8, 4.8.1, 4.8.2, 4.8.3, 4.8.4, 4.8.5, 5.0, 5.0.0.1, 5.0.0.2

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows

Reference #: 1695100

Modified date: 15 June 2016


Translate this page: