This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Deployment with multiple users

We have a scenario where multiple developers are now working on a single process app. They are either adding new functionality or upgrading the previous one. 

My question is how can we have developers keep working on the same process app while

1) only able to deploy tested changes.

2) avoiding unfinished changes from being deployed ( If one developer is still working on his task, how can we have the other developer deploy her changes to an environment),

3) these developers need to test their work to ensure changes are actually working as intended. So at some point, they'll need to deploy the changes to test. How can we ensure that only their work is being deployed and not another developer's unfinished work is getting deployed?

In short, how can we have multiple developers working on one process app without interfering with each other work?  

  • Suggested Answer

    It is best to try and coordinate and sequence your changes to minimize challenges. 

    But to answer your questions, it is important to understand how check in and publish operations work. Check in does make a change available to another SBM developer. So, if you can, just don't check in changes that aren't ready. Next, Publish publishes the contents of the local cache and does not care about what is checked in. So, if you are a developer that does not want someone else's changes, you can just choose not to get the latest and only publish and deploy based on what is in your local cache - just understand you run the risk of undeploying a change of another developer.

    Making use of one or more lower SBM environments also helps. You can for example both developers work in Dev, promote desired changes to Test, and promote successful changes to Prod. You will need to keep a close eye on versions of process apps and be prepared to rollback to an older tested version if for example the latest version is not desired or successfully tested. It is also important that you do thorough unit testing, and maybe even testing in Composer (such as Previewing forms), to avoid problems later.

    If you version/publish your process apps more frequently, making smaller more testable changes, then this will also help in the overall situation.

    Composer also has a Compare/Merge feature - this may help you apply or rollback changes on a more granular scale within a process app as well.

    I have successfully worked on teams of 3 or more SBM developers. I have used the approaches above as well as techniques in planning the work in terms of Sprints, and trying to assign developers changes to separate process apps when possible, or at least separate objects, to make it all easier and avoid conflicts. But ultimately, if everyone is aware of everyone else's planned changes, you can coordinate as a team. Smaller, less risky changes should be applied before more complex changes, and published separately, so that it is easier to keep them separate.