The current lifecycle is already in use.
The purpose of this change is to enable concurrent development, which were not permitted so far.
Besides inserting a new state, need also to change one state view association.
Yes, and it is a monumental pain in the rear-end. If you do this, then the versioninview table will not have the right content for the new state, and whilst it is technically possible to populate it, there are no tools to do so. The easiest and safest way to insert a new view is to add it to the end of the lifecycle and then rename the interceding views (and states).
For example, if you have Dev, Test, Prod and you want to insert QA between Test and Prod, then you might add NewProd (state and view) to the end of the lifecycle, then you promote all the packages in Prod to NewProd, rename Prod to QA (state and view) and rename NewProd to Prod (state and view).
Yes, I know I use an extra rename than I need to, but it helps remind you of where you are promoting packages to. If you were to insert lower down the lifecycle, say between Dev and Test, then you would need to promote the packages in Test to the old Prod. It is the act of promoting the packages through the state that updates the versioninview table.
Robert is correct.
If your new state is configured to have its own data view (not shared with another state), what you will have to do is to start with your highest state and *promote* all the packages in the highest state to your new state and then *promote" them back. Then go to the next highest state and do the same thing for all states higher than the new one you're adding. Make sure the "Verify Dependencies" checkbox is unchecked.
The other options are:
- Configure your new state to share a data view with an existing state.
- Create a new project, add to its baseline a snapshot of the production state of your existing project and then keep the existing project in read-only mode for reference.