From what I know if there is a problem with the deployment and you need to do it again and the developers were publishing during the deployment and they do breaking changes you will have problems and you will not be able to deploy a stable version, is just that. You can continue to publish but the last published version of the mod will be the one to be deployed. And you can continue to publish during the deployment, but before the deployment is what I said, the last published version will be on the deployment and you might have breaking changes that can impact the deployment.

I don't have hands-on experience doing deployment, but this is what I've experienced.

So yes, they can continue publishing, but don't make any major changes that could affect the deployment.

Regards,

Márcio

Hello,

As far as I know, it's safe to publish in an environment where changes are coming from (publishing in DEV when you're deploying to UAT) as soon as you have a deployment plan created. When you create a deployment plan in LifeTime, you're identifying what version of the application/modules that you wish to push - changes that are added after you've set your plan to a specific version will not be included.

It's the opposite that is dangerous: it is not safe to publish in an environment that is receiving changes. If you are deploying hotfixes to DEV, you should freeze new publishes until the deployment is complete. A concurrent publish can block or freeze your deployment plan.

Even if there is an error during your deployment and you now have newer, untested changes that you do not want to push, you can reuse a deployment plan that failed from the deployment plan list (/lifetime/Stagings_List.aspx) and clicking the "Reuse Plan" button. This will fetch the version that you wished to push, and will not include newer changes published after the plan was created.