New features in Lifecycle Services (LCS) enable you to configure when you get updates to your production environment and how you can pause an update when you are unable to take the update due to a critical business activity.
These features were only available to customers using version 8.1 and above. From today these features will also be available to customers that are using version 7.3. For customers that are on 7.3, LCS will update their sandbox and production environments to the latest Platform update each month.
For customers that are on version 7.1, 7.2 and 8.0, you can apply the latest platform update manually using the servicing flows.
With the features now available in LCS, you will be able to do the following:
• Configure whether to get Platform updates for your production environment in the first, second, or third week of the month and in what time zone.
• Pause updates through LCS if you are unable to take the update. You can pause a maximum of 2 continuous updates. However, if you are more than 2 releases behind, then you will not be allowed to pause updates. For example, if you are on Update 23 and the currently available platform update is Update 25, then you will be able to pause. But if you are on Update 22, then you will not be allowed to pause.
• Get notified about upcoming service updates through LCS.
Changes that will affect the servicing flows that will be released in the May 2019 update of Lifecycle Services (LCS).
Sign off on maintenance operations triggered through LCS
From 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 to 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 whether 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.
•T he sign off will only apply to a servicing operation, because that is the main operation where you validate the environment state to verify whether 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, whenthe environment is not in a terminal state (environment has a pending sign off), then LCS will not apply the update. There are often instances where customers forget to sign off on a previous operation and because that is the terminal state LCS skips the environment and doesn’t apply the update. As a result, customers ask us why LCS didn’t update their environments. With this change, sign off is managed separately, so if your environment is in a Deployed state then LCS 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. With a single package because it contains all of the changes it is easy to recreate the environment and you don’t need to worry about the order of packages applied.
This also helps with the CI/CD pipeline and provides reliability when doing the updates, because all of the dependencies are included in the package.
However, LCS doesn’t have any validation checks that enforce this best practice. Soon LCS will addi a warning check for Application deployable packages 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 when all of the modules on the environment are not accounted for in the package and in the list of modules to delete. When 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. 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. This new check to help with this transition and enforce the recommendation. From today you can manage customizations and third-party models from your build server.
In the near future LCS will also add a feature that allows you to create such a package from your development environment.
