Deployment Profile

Problem Statement:
The Deployment Profile (DP) or Deployment ID card (DID) captures information on the user stories and changes included in the build deployed to a planet. It is an extension of the Build#/Dockerize#. The Deployment Profile for a build deployed to GCC planets applies to InsuranceSuite (IS), Integration Gateway (IG), or any component/feature deployed into the GWCP. DP is like an ID card for a build. For IG Apps where downstream applications use different API versions, the DP can include the API version number to help BAs, QAs, and API guardians. The initial value of the DP can be set either: - automatically by TeamCity(TC) from the user stories that got to the build (more sophisticated) - manually by developers in TC using the Actions menu available in the Build Step Regardless of how we set the initial value for DP, we should be able to enter/edit/display this value from the GCC deployment page (for IS Apps from the IS deployment page, and correspondent page for IG apps or other components). As we can see the list of dockerized build in the IS Deployment page of GCC for deployment to the planets, I assumed that we have already integrated GCC with IG, and what I suggest here is an extension to this integration to display the deployment comment entered via TC in the GCC.

Persona / Use Case(s):
QAs, BAs, developers, and engineers will benefit from the deployment profile/ID card. Usually, these personas maintain details of the user stories deployed with each build to be able to assign tasks to their resources. Having this in GCC would simplify their process and also help them to ensure they are testing their story against the correct deployment. This would increase development and QA productivity.

Solution and Business Value:
There are ways to accomplish this: - In GCC, we should be able to enter, edit, and display the DP comments for each deployed published/dockerized build in a planet. - In TeamCity(TC), we can manually add a comment to a build from the build step. We can enter a comment for a build by choosing a particular build number from the build step (for example, the “Build Application” for IS) and selecting “Add a comment” from the Actions menu. This comment will be shown in TC whenever that build appears in the build list. Given that, in GCC, the initial value for the DP field for each build#/dock# is automatically taken from the TC build comment or, more sophisticatedly, from the build comment and list of stories associated with the build. As I mentioned before, DP is an extension to the Build#/Dockerize# and can be a section of one or more fields. - The About Page of IS Apps can include the deployment profile for non-prod and pre-prod stars. QAs and BAs who lack access to GCC and are testing the application would benefit from these details. - DP can initially be assigned by developers via TC and then can be changed in GCC to fulfill QAs, BAs, and guardians' needs. Outcome: IN GCC, for IS Apps when we navigate to IS Deployment for a specific planet, in addition to the App Status, Branch, Build#/Dockerize #, and Deployment status, we should display the Deployment profile or DP information. In the same page, we should be able to enter/edit/display DP value. DP initial value can be set either - automatically by TeamCity(TC) from the user stories that got to the build - manually by developers in TC using the Actions menu available in the Build Step About Page from IS can show details of the build, aka DP.

For any IS App and IG application or any feature deployed to GCC, QAs, BAs, developers, and engineers want to know the list or highlights of the changes included in that build. These personas rely on developers to get these details, as not all have access to the GCC or TC to find these details. Especially during the stabilization phase, the development team gets more requests from other teams to understand which bugs were fixed by each build deployed into their environments. In addition to these details, these personas want to understand what has changed for each major, minor, and patch API published by versioned IG Apps. So, from the API guardian's perspective, there is no relationship between Guidewire build#/dock# and the API versions (which API guardians maintain), and they need this information in GCC's UI as some of their downstream systems may point to a plant that is a few major/minor/patch versions behind. DP will be the ID card for the changes pushed to each planet, and having that will increase team productivity. Example for IS: Stories: US415839, introducing a search panel for audit entries US413044, Mega ProducerLoaad Split Example for IG, for API Changes: US123, Added major 2.0.0, Update renewal for adding new address type (XYZ) US 124, Changed Minor 1.3.0, TransferPolicyperiods changes, … US125, Added patch, 1.3.4, correcting mapper for assigned risk

Additional Information:
I have captured some images from the GCC and TC supporting my explanation of the solution that I couldn't share via this page. Please let me know if you need further information or need these images.