Note: You can add more rules and individual Approvers using our separate Approvals feature.
Tulip uses two types of versions for all apps: a development version and a published version. This allows you to make changes as a Tulip administrator without affecting the version that is live on the production floor.
When taking an app from the development stage to releasing it on the production floor, creating and managing versions becomes an important part of your workflow.
Here's your guide to doing version control in Tulip.
The Development Version
The initial version of all apps is a Development Version. Once you are ready to put an application into production, you should make a read-only version of it, which is achieved by publishing a version of the app.
Think of a published version as an unmodifiable (‘frozen’) copy of the development version at the time of publishing. There is no limit to the number of published versions of you can have of an app.
Publishing a version of an app creates a read-only copy of the development version.
Since all ‘published’ versions are read-only, modification to an app can only be done through its development version.
To put it simply, you create and edit apps using the development version. When you are ready to put a new version of the app into production, you should publish it.
Stations can be configured (in the Shop Floor screen) to either run the development version or the most recent published version. Usually, you will want to run the published version
Version implication on data collection and validation
Each time an app is used on your production floor, data is collected. Tulip will automatically track which version of the app was used by the operator when completing their workflow.
The advantage of publishing versions of an app is that the app is immutable and prevents inadvertent changes from being sent out to the production floor. This structure allows for the establishment of a validation process.
Each published version of an app is saved with a name and a time stamp.
Good Documentation Practice (GDP) requires you to save each version with a unique name that includes:
- the revision of the app
- the ID of the app (if it exists)
- the name of the app.
The date of publishing is automatically captured in Tulip.
Publishing An App
In order to publish an app, follow these steps.
- Select the app you would like to publish from your list of Tulip apps.
- Navigate to the "Versions" tab in the App Summary View.
3. Click the “Publish” button on the right hand side of the row with the development version, as shown in the image below.
The version will be automatically numbered, and you can add a description to share changes with other team members.
Once you have created a published version of the app you will notice a new row is added to the versions table with the title "Version X".
You can view the published version of the app by clicking the "..." button and choosing "View".
If you click "View" after publishing a version, you will notice that all editing tools are greyed out.
Note: In general, only a published version of an app should be used in production, otherwise you run the risk of having the app definition change while operators are following the steps.
It is also easier to track meaningful data trends when using a published version, otherwise all completions and data collection will simply be reported under ‘Development version’ regardless of changes made to the app which could alter the interpretation of that data.
It is also possible to publish an app from the App Builder. The steps to be followed have been described below:
- Click the "Publish" button in the top right of the screen.
- Add some details in the description field and click "Publish Version X"
Sometimes, you need to "roll back" a previous version of the app to make some slight changes using the "Restore" button.
However, you may be already working on the development version, and you will not want to erase your work.
This is where "snapshots come into play. Use the "Create Snapshot" button to save the development version separately.
The snapshot is "frozen", but you will be able to restore it to the development version later.
This is also helpful when you want to create two versions of an app for a teammate to review. You can save one version as a snapshot and continue editing the second version as the development version.