We want to have 2 version for an application,
Version1 will be the first release, when version1 on PROD, we want to start version2 implementation, that means we'll have 2 versions in the same time.
We found there's a trouble to have the version control, because we have one base line, but need to support 2 versions with their own features, the objects will get conflict around both versions.
My questions is there any best practice to handle such case?
Discussion posts and replies are publicly visible
Can you clarify what "version 2" will be? Is it a completely separate implementation? Or do you simply mean the (more common) use case of an iteration on the original production version?
Either one is pretty easy to do. If it's completely separate, then you simply start a new applicaiton package and create all new objects (and where needed, separate copies of any of your original objects, at least where they'd require changes for version 2).
Instead, if it'll be iterations of the current functionality, you merely develop them and deploy them up through the usual dev -> test -> prod (etc) progression, and make sure any process forms you improve are built with handling legacy instances in mind, where necessary.
version2 is a separate implementation, but how to copy Process Model, Record Type objects? Seems like Appian didn't provide the duplicate feature
Creating a copy of a process model is very simple - either via "save as" or via "create new process model as a copy of..." functionalities.
For the Record Type - you should consider very carefully whether you really want it to be a duplicate. if so, i believe you'll need to manually recreate it.
Appian does not support code branching in the way I think you're suggesting you want. If you develop Application A and release it as Version 1 (i.e. A.1) into production then as soon as you start to make changes to it in Dev you are in effect working on A.2 If you need to provide support for A.1 whilst A.2 is under development then a typical solution is to have a hotfix environment which has the latest A.1 code, make changes and test there, and then push your changes to Prod and to Dev and then up your development environments until all of your changes to A1 are aligned across all environments . Pushing changes to Dev does run the risk of losing any changes for those changed objects in A.2 but that's a small price to pay for a hotfix capability (usually such hotfixes impact a small number of objects)