Learn how to use the development and published versions of your app to control when new changes should go live. You can add more rules and individual Approvers using our separate Approvals feature.
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 for each individual 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
Benefits of Publishing an App
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 Published 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.
All of these fields are automatically tracked in Tulip, including the date that the app was published.
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.
- 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.
It is also possible to publish an app from the App Editor. 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"
Using Published Apps On the Shop Floor
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. If the app is being used at a Station, then the new version will go live to that station when the app is "Completed" or "Canceled".
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.
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.
Did you find what you were looking for?
You can also head to community.tulip.co to post your question or see if others have faced a similar question!