Upcoming changes to the servicing flows triggered through Lifecycle

We want to notify you of the changes that were making to the servicing flows that will be released in the May 2019 update of Lifecycle Services (LCS).

Sign off on maintenance operations triggered through LCS

Today, on completion of any maintenance operation (servicing, database movement, upgrade, and putting system in maintenance mode) you have the option to sign off or sign off with issues as the last step to indicate completion of the operation. Only after you indicate sign off, is your environment ready for the next operation. The following changes we will be made to streamline the sign off process:

• Going forward the environment will be ready for the next operation after the current operation has been successfully completed. This means that sign off is no longer the terminal state but rather it is the completion of the operation. Operation completion states are now Successful, Rollback Successful, or Aborted.
• The Sign off button will be moved to the Environment history page, so after the operation is complete, you can navigate to the Environment history page to indicate sign off if you want to validate and capture this information.
• The release candidate check for moving packages from sandbox to production will continue to check if the package was successfully applied in a sandbox before you can move it to production. It does not depend on you signing off on the update.
• The sign off will only apply to servicing operation as that is the main operation where you validate the environment state to verify if there are any issues. For other operations, such as database movement, upgrade and maintenance mode, sign off does not apply and will not be visible.
• For service updates pushed by Microsoft, if the environment is not in a terminal state (environment has a pending sign off), then we do not apply the update. We see many instances where customers forget to sign off on a previous operation and because that is the terminal state we skip the environment and don’t apply the update. As a result, many customers ask us why we didnt update their environments. With this change, sign off is managed separately, so if your environment is in a Deployed state we will apply the update.

Provide a single package containing all customizations and ISV solutions

One recommended best practice is to provide a single package containing all customizations and ISV solutions when doing updates to your environment. The reason for this best practice is that with a single package containing all the changes it is easy to recreate the environment because you don’t need to worry about the order of packages applied. This also helps with CI/CD pipeline and provides reliability when doing the updates, as all the dependencies are included in the package. However, we dont have any validation checks that enforce this best practice. Soon we will be adding a warning check to highlight that there is a difference in the modules that exist on the environment and what is available in the package that is provided during deployment. This will initially be a soft-check but will later become a hard check that will prevent you from applying updates if all the modules on the environment are not accounted for in the package and in the list of modules to delete. If there are modules that are listed in the ModuleToRemove file, then those will be deleted. With the new self-service deployment feature, it is required that you use a single package because whatever is available in the package overwrites what is on the environment. Today, self-service deployment is available only to new customers signing up for Finance and Operations; however, existing customers will be soon be migrated to this feature based on their Azure region. We are adding this new check to help with this transition and enforce the recommendation. In addition to this, today you can manage customizations andthird-party models from your build server. In the near future we will also be adding a feature that allows you to create such a package from your development environment.

The post Upcoming changes to the servicing flows triggered through Lifecycle Services (LCS) appeared first on Microsoft Dynamics 365.