Sites lifecycle

<< Click to Display Table of Contents >>

Navigation:  Enterprise Subscription > Sites >

Sites lifecycle


Bizagi Sites is available in all your environments that have a Work Portal. This makes Sites very versatile when it comes to developing and launching a site. All your environments have access to a Sites editor where you can edit, download, upload and publish sites.



Remember that the Sites Editor is only available for Bizagi users (including admon) who have the "Sites Editor" role.




We strongly suggest you follow these steps when creating and launching your site:

1.Build your site in the Development environment

2.Download your site from the Development environment, and give your site a version

3.Upload the site to your Test environment

4.Publish the site in your Test environment

5.Perform tests on your site

6.Fix any issues in the Development environment (not in the Test environment), and go back to step 2

7.When all the tests in the Test environment are fulfilled, upload the approved site to your Production environment

8.Publish your site in the Production environment


Note: For steps 3 and 7, make sure you have deployed to your Test and Production environments the stakeholders and collections you are using for your site.


Continuous improvement

As you may know, the development cycle doesn't end when the product is launched into the Production environment. The product evolves and improves over time. With this in mind, this is the recommended procedure for launching your site using Bizagi Sites. Whenever you include changes to your site and it's ready to be tested, download and give your site a version.


If there are elements of your site that need to be fixed, you must fix them in your Development environment. After you're done fixing, download your site, give the output file a version and upload it again to your Test environment.


When the site is approved by your quality team, you can upload the approved output file to your Production environment. If there are no warnings in production during the upload, publish the site without making any changes to the content. If there are warnings you must hold the upload and wait until the missing items are available in your Production environment.


How to version your sites

We recommend you use Semantic Versioning for the output files you download from the Development environment, to keep track of your site's evolution over time. Semantic versioning recognizes mayor and minor versions and changes.

The following table provides a guideline for versioning your Sites:






Adding or removing stakeholders

Adding or removing pages

You add a new Stakeholder to your site.

Previous version number: 1.9

New version number: 2.0


Hot fixes

Style changes

Image changes

Content change

You change the company logo.

Previous version number: 1.9

New version number: 1.10



Hot fixing

Hot fixes are those fixes that need to be done in the Production environment. We recommend only hot fixing typos.

To fix the typo edit the site on your Production environment and publish it.



All changes made to the site in the Production environment must be mirrored in the Development and Test environments.


To reproduce your hot fixes in the Test and Development environments, you can either download the site from Production and then upload it to your other environments or manually copy the changes in the other environments.


Warning messages when uploading a site

Make sure your site's stakeholders and collections are available in your environment, Sites displays a warning icon on those which are not available.

When there are warnings, you should first deploy the missing stakeholders and collections to your target environment before continuing. Once there are no warnings, upload your site and avoid making any changes to your site in this environment. Once the site finishes uploading, publish it and perform your tests.