Updating and upgrading your deployment

The processes of updating or upgrading your deployment are similar to each other, but the scope of the changes required in each differs.

Upgrading, which means implementing a major or minor software release into your deployment, involves significant changes in features and functionality. The instructions for implementing a major or minor release are described in the upgrade guide, for example: Upgrading IXIASOFT CCMS from 4.x to 5.1.

Updating, which means implementing a build into your deployment, only involves small updates to the IXIASOFT CCMS components or minor configuration changes. Although the scope of the changes differs between them, the process for applying those changes is the same. The instructions for implementing a build release are described in the version's update guide, for example: Updating an Existing DITA CMS Core v4.5 Deployment Guide (Update Guide).

For any change you need to make in your deployment, your main concern should be to avoid disturbing your production environment as much as possible. This means that you need to identify exactly what changes you need to make, how to make them, and what the consequences of those changes are.

Since each deployment is different, you should attempt the changes on a separate environment not used for production. This environment is often referred to as a test environment. The purpose of making changes in a test environment first is to learn what is needed to adapt the general instructions provided by IXIASOFT to the specific requirements in your deployment. The goal is to produce a set of procedures documenting specifically what you need to do to your production environment.

Once you have this set of procedures, you need to test them on a copy of your production environment to verify and confirm that the instructions are complete and correct, the changes were applied successfully in the environment, and that you have not broken something (caused a regression) as a result of the changes. This environment is referred to as a validation environment.

After you have confirmed that the procedures are correct and the changes are approved, then they can be applied to the production environment. This might mean that you give the procedures to your corporate IT department to implement or you might be responsible for implementing the changes yourself.

Although this might seem to be redundant work, it is standard practice in IT which serves to reduce the risk of disrupting the production environment.