How-To Migrate a Project to a Production Environment Using Solutions

How-To Migrate a Project to a Production Environment Using Solutions


In the 4.0 version of the OutSystems Platform we introduced the Solution concept in Service Center as already presented in the What's New in the OutSystems Platform 4.0.

In this post we will further drill down this new concept an present a best practice recipe to migrate projects to production. We will assume that you have already created a Solution with all the Components of your project.

Before the migration to production, there are some steps you should perform in the development Hub Server:
  • Publish the Solution Running Version: This step will ensure that all the references are refreshed and up to date.
    The publishing of the Solution Running Version will (re)publish all the currently published Components, either eSpaces and/or Extensions, and their required Dependencies, e.g., producers. The Running Version differs from the traditional source version control systems HEAD because it is not composed by the Components’ latest versions. For instance, imagine you have two versions of an eSpace, v1 and v2, that v2 is more recent than v1 and that the published version of the eSpace is v1. The traditional HEAD version would pick v2 because it is more recent, but the Running Version will pick v1 because that is the version you have chosen to use, that is, the version you decided to publish.
  • Create a Solution Version: This is the version you’ll run the tests over and will migrate to production.
    In the Solution edition screen you have a button to create a new Solution Version. The creation of a Solution Version allows you to take a photograph of you project. This version will remember all the Components and respective Dependencies you were using at its creation time. To be more exact, the Solution Version will actually remember the specific versions of your Components and Dependencies. You can latter rollback your project to that state by simply publishing the Solution Version. When you do so, you are assured that the Components and Dependencies specific versions are published and all the references refreshed.
  • Run your Tests: Run the unit and/or functional tests you have created.
    Testing is a must in any methodology not only to make sure the new features work as expected but also to make sure new changes didn’t break older features. There are a myriad of Quality Assurance (a.k.a. QA) tools, namely the Selenium Test Automator available in OutSystems’ Community Solutions page.
  • Download the Solution Version: Download the created Solution Version to migrate to production.
    Solutions can be downloaded into a single file known as OutSystems Solution Pack (.osp). You can download any Solution Version and the Running Version. This Solution Pack will contain all the Components and required Dependencies to seamless deploy the Solution in another Hub Server or simply back it up.

After you ensured that all your tests succeed and downloaded the OutSystems Solution Pack, you are now in conditions to migrate the new version of your project to the production Hub Server:
  • Create a Safe Rollback Solution Version: Make sure you create a Solution Version with your current production project.
    Just to be safe, you should always have a backup plan so it is wise to create a Solution Version with your currently running production environment. This way, if by any chance you find any problem in your new version, you can always easily rollback to the previous version and calmly fix the problem using the development environment.
  • Publish the Solution Pack: Publish the Solution Pack downloaded from the development Hub Server.
    Solution Packs can be published with one click under the Solutions section in Factory tab of Service Center. The publish of a Solution Pack will create your Solution if it doesn’t exists and publish all the Components in the pack.
  • Run your Tests: Run the unit and/or functional tests you have created against the production Hub Server.
    As a safeguard, and as the development and production data is certainly different, you should have tests over the production Hub Server. A safer alternative though, is to have a QA Hub Server with a clone of the production persistent model to execute the tests. This way you guarantee for sure that the tests won’t cause problems in the production environment.

Hope to have provided some more insight about the Solutions concept. Feel free to pose any questions.


Rodrigo Castelo
Have there been any updates to this process for the newer versions of the platform?