Sites lifecycle

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Sites >

Sites lifecycle

Overview

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.

 

note_pin

Remember that the Sites Editor is available for Bizagi users who have the Site Editor role or the Administrator role. We strongly recommend you to set the Site Editor role as described in Accessing the Sites Editor.

 

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

1.Verify that your configured stakeholders have at least one available context, as it is required for you to start creating sites. To validate this, access Bizagi Studio and click the Export/Import tab. In the Deployment sub-menu, select Export and then click Experience. The stakeholders you want to export must have checked at least the By default context that appears in the Contexts drop down list.

 

SitesJourney01a

 

2.Build your site in the Development environment

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

4.Upload the site to your Test environment

5.Publish the site in your Test environment

6.Perform tests on your site

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

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

9.Publish your site in the Production environment

 

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

 

When working with a Partner or with Bizagi’s Professional Services

When a project is developed by a Partner or Bizagi’s Professional Services, the access to the Sites Editor in Testing or Production environment is restricted. In those cases, the Sites lifecycle can be as follows:

 

1.Verify that configured stakeholders have at least one available context.

2.Build your site in the Development environment

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

4.When the required metadata is present in the Testing environment, enable a user with the Sites Editor role (we can call them Site Editor User).

5.The Site Editor User can Upload the site to the Editor in the Testing environment.

6.The Site Editor User can Publish the site in the Test environment

7.Perform tests of the Site in the Test environment.

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

9.When all the tests in the Test environment are fulfilled, enable a user with the Sites Editor role in the Production environment

10.The Sites Editor User can upload the approved site to the Production environment

11.The Sites Editor User can Publish the site in the Production environment

 

 

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:

 

Version

Changes

Example

Mayor

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

Minor

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.

 

note_pin

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.

 

SitesJourney01