The OutSystems ecosystem is divided into components with different release cycles: Platform Server, Development Environment and LifeTime Management Console. In this article we will focus on the upgrade of the core server part of OutSystems product, the Platform Server.
Upgrading your OutSystems environments to a new Platform Server version is a four-step process that requires preparation since it may impact your applications (all your applications will have a new version after the upgrade). The steps are: Analysis and Preparation, Planning, Execution, and Testing.
If you want to take this information offline, please check the Upgrade datasheet that describes the overall procedure detailed in this guide.
Up to version OutSystems 10, upgrading OutSystems to a new major version means upgrading all the infrastructure - LifeTime management console and the application environments.
From version OutSystems 11 onwards, LifeTime is distributed independently from the Platform Server, which enables both components to have different upgrading paces.
When upgrading your infrastructure, make sure the LifeTime is the most the most up-to-date environment. If you’re running OutSystems 11 you can take advantage of its continuous update cycle. If you are running OutSystems 10 or previous, first you must upgrade your LifeTime Management console to the latest version.
Starting on version 11, LifeTime is only supported when installed in a dedicated environment. If you still have it installed in an application environment, please check the reinstallation guide.
Analysis and Preparation
Before we start the upgrade, we should always learn more about the specific release. Start by understanding what are the new features, improvements, and security and bug fixes.
Then, it’s important to assess the impact that the upgrade may have in your applications and infrastructure, checking the Side Effects and Breaking Changes documents:
- Side Effects and Breaking Changes in OutSystems 11
- Side Effects and Breaking Changes in OutSystems 10
Be sure to read all the documents that might impact your upgrade. For example, if you're upgrading from OutSystems platform 9.1 to 11, read the breaking changes for versions 10 and 11.
The second phase is the planning. Based on the breaking changes identified you should estimate how long it will take to perform all the needed code fixing, and to publish all the applications to the new version.
Make sure that your team is involved (Development Team and Test team will be needed) and plan ahead, so the upgrade is aligned with your release cycle.
An upgrade sprint should never break a development sprint!
An upgrade should always be between development sprints (if you have teams at a different speed, make the necessary adjustments).
Validate the best time to upgrade the Production environment and plan the remaining environment upgrades from there.
Upgrading the Platform Server of an environment or a set of environments should always follow the staging lifecycle of the applications in that infrastructure, so you should prepare your applications for a full staging from Development all the way to Production.
You have the freedom to choose the order that is most convenient for you and your customers. Sometimes, to best coordinate with the development teams and on-going projects, one can start with other non-production environment (e.g., pre-production) to fully validate the applications upgrade, and then upgrade the Production environment. Only after, upgrade the Development environment according to the development teams delivery sprints. Bottom line is, you should always upgrade and test your applications in a non-production environment before proceeding to the production environment.
Once you have your Upgrade plan defined and the development and test teams allocated, you can then proceed with the Upgrade itself.
Starting on the Development environment, follow the procedure that corresponds to your installation type.
Upgrade Platform Server
In the OutSystems Cloud, the process of upgrading the Platform Server is handled by OutSystems, coordinating with you in every step of the way, to guarantee a successfully and as effortless as possible procedure, consisting of the following high-level steps.
You can request the upgrade of your OutSystems Cloud infrastructure to a supported upper version, by opening a Support Case using any of the available mechanisms.
OutSystems will promptly contact you to schedule and plan the Platform Server upgrade.
OutSystems proceeds with the upgrade of the Platform Server component on the environment on the agreed schedule.
Upgrade the remaining environments, preferably according to staging order, following the same procedure, with coordination between you and OutSystems to find the best schedule for each of the environments.
OutSystems is only responsible for the Platform Server upgrade. Once the OutSystems software (System Components included) is updated in the environment, the customer is responsible for:
- Re-deploying applications (Upgrade Applications to the new version)
- Resolving any breaking changes
Your Datacenter (On-Premises / Private Cloud)
If the environment is running in your own private cloud or on-premises, the upgrade process is fully managed by you, without the direct involvement of OutSystems. However, at any time you can ask OutSystems Support for assistance if you have any questions or get any errors in the process.
The process is the following:
Download the latest version of the Platform Server installer.
Follow the Installation Checklist for the correspondent version. In the Installation Checklist (e.g., 10.0, 11.0), select “Upgrade to a new Major Release” (or “Upgrade to a new Release or Cumulative Patch” if you are just updating your environment), and follow the instructions.
Follow the same procedure to upgrade the remaining environments, preferably according staging order.
Go Live Strategies
When upgrading the Platform Server you should take into account that the environment is literally under maintenance. That being said, if you already have Live applications, this process may impact them and, as such, you should define a strategy for the upgrade of your Production environment, based on the priority of your applications.
A Downtime approach is the safest way to perform an upgrade and advised when there are no business requirements for zero-downtime. By stopping the production environment and preventing end-users access, the Upgrade process consistency is guaranteed, and a rollback can happen with no data loss.
A Zero-Downtime Upgrade is like changing a car engine without stopping the car itself. Which means that if you need to rollback, you will most certainly have data loss. To perform a Zero-Downtime Upgrade, with success, your environment requires multiple Front Ends in each OutSystems Zone. If you don’t have this feature enabled you can’t proceed with this solution. The Upgrade process is done by:
- Disabling the Front-end servers in Service Center.
- Upgrade the platform in the controller node.
- In the load balancer disconnect half of front-end servers in each zone.
- Upgrade those servers and then enable them in Service Center
- Switch the active Front-End servers in the Load Balancer to the upgraded ones
- Upgrade the remaining Front-End servers.
- Finally, reconnect all servers to the Load Balancer.
Upgrade Development Tools
Download and install the correspondent development tools in the developers’ workstations.
Upgrade Applications to the new version
At this stage, it’s important the teams availability in order to perform all the needed code fixing (solving breaking changes) and testing.
Once the Platform Server is upgraded you should upgrade your applications, republishing all the modules to the last version, according the following scenarios:
On the development environment, the fastest way to upgrade all your applications is by creating a Solution with all modules and Publish the "Current Running Version". If you get any errors publishing the solution, use the appropriate development tool to open the correspondent module and fix the problems. In the end, you can publish the whole solution again to make sure all issues and dependencies are properly resolved.
For non-development environments it’s recommended to stage the application modules from a previously upgraded environment. Using Service Center (https://YOUR_ENVIRONMENT/ServiceCenter), download the solution and publish it in the new environment, ensuring you don’t overwrite System Components. LifeTime management console can also be used to stage upgraded applications, when the lifecycle of the applications is perfectly aligned with the upgrade.
Have in mind that this approach for non-development environments is only applicable when the version of the applications on the previous environment is stable and ready to be staged to the next environment (upgrade must be aligned with your release cycle). If that’s not the case you should perform a code-based upgrade, doing all the fixing and testing directly in each environment.
Finally, you should create and run tests to assure that your applications hot-points are not affected by the upgrade. Test your applications (screens, workflows, operations, etc.), check for application errors or background issues in Service Center’s Errors Log, to guarantee that all the applications are running as expected.