This Blog aims to showcase how a Company using HWA and maintaining all its Application Code on GIT alongwith all Scheduling Objects could also promote and manage the entire Code Promotion using HWA while also tracking the Whole Process on Service Now.
We consider that the Customer has three Code Repositories called QA_Repo , PREPROD_REPO ,PROD_Repo .Customer would promote his Application Code+Scheduling Objects from QA_Repo to PREPROD_Repo or alternatively from PREPROD_Repo to PROD_Repo .
A Request is placed on Service Now by the relevant Application Team whenever they have to promote all the Application Code+Scheduling Objects from one Environment to the other.
The Code Promotion of the Application Code+Scheduling Objects is completely orchestrated in HWA End to End and also tracked on Service Now.
Consider that the below request is raised on Service Now by the Inventory planning Team needing to promote their Application Code+All Scheduling Objects relevant to Inventory Planning from PRE-PROD ENV to PROD ENV:
The request raised on Service Now has a Field called Automation which is set to “YES” to indicate this is a request to be processed through HWA. It is raised to the Assignment group : GIT_Code_promote and the description Field in the Request has the Application Name mentioned as InvPlanning colon separated by the Source ENVName and Destination ENV Name as “InvPlanning:PREPROD_Repo:PROD_Repo”.
The job would be a RESTFUL GET Job that would read the details on the Ticket from Service Now and would store the details on the Ticket in an output file called /tmp/requestsgitcodeprmoutput.
This Job would be a Unix Job which would Extract the Ticket Number from the Output File /tmp/requestsgitcodeprmoutput.
This is a Unix Job which would extract the Source Environment from the Output File /tmp/requestsgitcodeprmoutput.
This is a Unix Job which would extract the Target Environment from the Output File /tmp/requestsgitcodeprmoutput.
This Job uses the jobprop utility of HWA to store the Ticket Number(internally referred to in SNOW as the sys_id) into a HWA variable called TKTNO:
This would be a Unix job to set the Global Config for UserName and Email:
This job initializes the GIT Repo locally:
The Job pulls the Application Code and Scheduling Objects stored in the PrePROD Repo into the Local Repository, we have Similar Jobs : GIT_PULL_QAREPO:
This job checks out and creates a new branch called testhwa from the existing branch called master . Likewise we have a similar job called GIT_BRANCH_QAREPO.
The Job GIT_ADD adds all application Code+Full Dump of HWA Scheduling Objects to the local Repository:
The Job does a remote add to the GIT Repo PROD_Repo from the Repository PREPROD_Repo:
The Job GIT-COMMIT-ADD does a commit on Code and Scheduling Objects Definitions to be promoted into the PROD ENV:
The GIT Push Job would push the Application Code and Scheduling Objects Definitions to the target PROD Repo on GIT and would pass conditional dependencies PUSHSUCCEDDED(RC=0) incase the promotion of Application Code+Scheduling Objects was Successful else would return PUSHFAILED (RC>0 non-Zero Return Code) to indicate that the push was not Successful.
Likewise we have similar GITPush jobs called GIT_PUSH_PREPROD_REPO for the other Flow to promote from QA to Preprod.
Here’s the Jobstream once it is fully developed to include two branches from QA to PRE-PROD and from PRE-PROD to PROD depending on the input in the Service Now Request:
The SNOWGITREQUEST_TICKET_CLOSE job closes the Ticket in Question , the TKTNO Variable is passed to this job and it makes a RESTFUL call into SNOW to close the Request in question.
We have conditional dependencies defined depending on the inputs in the SNOW Request which could be Source ENV : PRE-PROD to Target ENV : PROD or Source ENV : QA to Target ENV : PROD , likewise two Flows Branch out from these two jobs one to promote Application Code+Scheduling Objects from Pre-PROD to PROD or from QA to PreProd:
Each of the two Flows would run : GIT Init , GIT Set Config , GIT Pull Repo , GIT New Branch , GIT Add , GIT Remote Add , GIT Commit and GIT Push Steps.
Conditional Dependencies are defined from the GIT Push Steps called PUSHSUCCEDDED and PUSHFAILED.
A Join Dependency defines an OR Condition that gets satisfied when one of the GIT Push jobs in one of the Flows passes PUSHSUCCEDDED Condition.
The Whole flow when executed against this request would run as follows:
The Flow which gets executed depending on the conditional dependencies from Source ENV and Target ENV Jobs would run while the other Flow would get supressed .
Conclusions from the UseCase:
In any Customer Environment the Application Code and HWA Objects Definitions need to be maintained in a Code Repository like GIT and the promotion from one Environment to another can be managed entirely out of HWA and there is no need of any external manual steps while tracking the promotion on Service Now for approval as well.