Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

This article explains basic release flow only. Depending on the feature implementation details, there might be additional steps required such as updating applications that are common to both TCMH and Seafarer Services (SS), db scripts, LoV changes, etc. For more complex deployments, it might be a good idea to have a work item created that details additional steps and/or include these steps in the SMGS ticket’s plan.

Instructions

  1. One week before anticipated release, be sure to create an SMGS ticket for any on-premise applications that must be deployed. /wiki/spaces/MAR/pages/158138386.

  2. By now you might have a release branch created, ideally under a release folder in your code repository. If not, create a release branch and tag the ‘develop' branch with the release number for tracking purposes.

  3. Create the application builds by running the TCMH pipelines at this location against your release branch. They need to be executed individually because they are not set to trigger automatically. Please note that the Azure pipeline will containerize the CertificateProcessingRemote.API application and push to the shared container registry at this location. The on-premise applications are placed in their respective drop folder directories to be used in a release pipeline.

How to deploy CertificateProcessingRemote.API

  1. Go to Deployment Center blade of the app service and select the image build that you just created; after saving, the app service will load the new image.

How to deploy the on-premise applications

  1. After your change is approved in SMGS by the Change Control Board (CCB), you will be provided with a staging location for your deployment package. Navigate to the production release pipeline, select Edit and change the staging variable value to the value provided by CCB.

  2. Save your change and rune the release. This will push the on-premise zipped packages to the staging folder.

  3. It is also common practice for the change owner to include a copy of the deployment plan for the web team in the staging folder for the attention of the web deployment team. This is also an opportunity to make any necessary changes because at this point the plan in the SMGS ticket can no longer be modified.

  • No labels