Skip to main content

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

OutSystemsプラットフォームをアップグレードする

Overview

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.

LifeTime Upgrade

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 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:

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.

Planning

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 happen 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 another 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.

For (Pre-)Production you should create a custom checklist containing all the requirements and steps to be executed in production, following a downtime or zero-downtime approach.

Execution

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

If you are using a personal environment and you would like to upgrade it to the latest version please refer to the article Upgrade a personal environment to the latest version.

OutSystems Cloud

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 successful and as effortless as possible procedure, consisting of the following high-level steps.

  1. 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.

  2. OutSystems will promptly contact you to schedule and plan the Platform Server upgrade.

  3. OutSystems proceeds with the upgrade of the Platform Server component on the environment on the agreed schedule.

  4. 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:

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:

  1. Download the latest version of the Platform Server installer.

  2. 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.

  3. 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.

Downtime Upgrade

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.

Zero-Downtime Upgrade

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:

  1. Disabling the Front-end servers in Service Center.
  2. Upgrade the platform in the controller node.
  3. In the load balancer disconnect half of front-end servers in each zone.
  4. Upgrade those servers and then enable them in Service Center
  5. Switch the active Front-End servers in the Load Balancer to the upgraded ones
  6. Upgrade the remaining Front-End servers.
  7. 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 to 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 all non-development environments (i.e. Testing, Production, etc.), 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. The 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.

Testing

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.

この記事では、OutSystemsプラットフォームを新しいメジャーバージョンまたはマイナーバージョンにアップグレードする方法について説明しています。アップグレードプロセスを評価して、その影響を理解し、それに応じてアップグレードプロセスを計画できるようになります。

はじめに

個別のリリースの詳細については、該当するバージョンの新機能のドキュメントをご覧ください。

新しいメジャーバージョンへのアップグレードがアプリケーションに及ぼす可能性のある影響を評価するには、以下に示す副作用および互換性を破る変更に関する各ドキュメントをご覧ください。

アップグレードに影響を及ぼす可能性のあるすべてのドキュメントを必ずご覧ください。たとえば、OutSystems Platform 8から10にアップグレードする場合は、バージョン9、9.1、および10に関する互換性を破る変更をご覧ください。

概要

1つの環境または複数の環境をOutSystemsプラットフォームの新しいメジャーリリースにアップグレードする場合は、インフラ内のアプリケーションのステージングライフサイクルに常に従う必要があります。インフラに管理コンソール(LifeTime)の専用環境がある場合は、その環境を最初にアップグレードする必要があります。専用環境がない場合は、ステージングプロセスの順序で各環境をアップグレードします。ほとんどのユーザーは、Productionに環境をプッシュするのと同じ順序で環境をアップグレードします。たとえば、以下のような順序になります。

Development > Testing > Pre-Production > Production

ただし、お客様やお客様の顧客にとって最も作業しやすい順序を自由に選択できます。場合によっては、開発チームと実施中のプロジェクトの最適な連携を図るために、まず他の非本番環境(本番前環境など)でアプリケーションのアップグレードを十分に検証したうえで、Production環境をアップグレードすることもできます。その後、開発チームのデリバリースプリントに従ってDevelopment環境をアップグレードします。つまり、必ず非本番環境でアプリケーションをアップグレードしてテストした後に本番環境に進む必要があるということです。

OutSystemsプラットフォーム環境をアップグレードする全プロセスを以下に示します。

  1. 環境のPlatform Serverをアップグレードします。
  2. 環境にアプリケーションをパブリッシュする開発者の開発ツール(ダウンロードページのDevelopmentクライアントツール)をアップグレードします。
  3. 以下に示すシナリオのいずれかに従って、すべてのモジュールを再パブリッシュします。

    A)新しいメジャーバージョンにアップグレードする場合は、以下の手順を実行します。
    • 開発環境をアップグレードする場合は、すべてのモジュールを再パブリッシュしてアップデートし、新しいバージョンの修正や改善を利用できるようにします。通常、すべてのモジュールを一度にアップデートするには、すべての拡張機能およびeSpaceを含むソリューションをService Centerで使用している必要があります。
    • 開発環境以外では、すべてのモジュールの再パブリッシュは推奨されません。代わりに、以前アップグレードした環境からソリューションをステージングすることを推奨します。以前の環境で、Service Centerを使用してソリューションをダウンロードし、新しい環境にパブリッシュして、システムコンポーネントが上書きされないようにします。

    B)新しいマイナーバージョンにアップデートする場合は、以下の手順を実行します。
    • ご利用の環境で、すべてのモジュールを再パブリッシュしてアップデートし、新しいバージョンの修正や改善を利用できるようにします。本番環境では、開発者の監督のもとでこれを行うようにしてください。通常、すべての拡張機能とeSpaceを含むService Centerのソリューションを使用して、すべてのモジュールを一度にアップデートする必要があります。

OutSystemsプラットフォームのアップグレード

OutSystemsプラットフォームのアップグレードを実行するには、以下の対応するガイドに従い、データセンターまたはOutSystems CloudのどちらかでOutSystemsプラットフォーム環境をアップグレードする必要があります。

どちらのガイドに従えばよいかわからない場合は、OutSystems Supportにお問い合わせください

アプリケーションのアップグレード

OutSystems環境をアップグレードした後にアプリケーションをアップグレードするには、「アプリケーションをOutSystemsプラットフォームの新しいバージョンにアップグレードする」の記事をご覧ください。