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:
Fig1
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”.
Solution Realization:
SERVICENOW_GET_REQUESTS_GITREQUEST Job:
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.
Fig2
EXTRACT_REQUEST_TKTNO_GITREQUEST Job:
This Job would be a Unix Job which would Extract the Ticket Number from the Output File /tmp/requestsgitcodeprmoutput.
Fig3
EXTRACT_REQUEST_SOURCEENV_GITREQUEST Job:
This is a Unix Job which would extract the Source Environment from the Output File /tmp/requestsgitcodeprmoutput.
Fig4
EXTRACT_REQUEST_TARGETENV_GITREQUEST Job:
This is a Unix Job which would extract the Target Environment from the Output File /tmp/requestsgitcodeprmoutput.
Fig5
STORE_TKTNO_GITREQUEST Job:
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:
Fig6
GIT-SETCONFIG Job:
This would be a Unix job to set the Global Config for UserName and Email:
Fig7
GIT_INIT_2 Job:
This job initializes the GIT Repo locally:
Fig8
GIT_PULL_PPREPO Job:
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:
Fig9
GIT_BRANCH_PPREPO Job:
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.
Fig10
GIT_ADD_2 Job:
The Job GIT_ADD adds all application Code+Full Dump of HWA Scheduling Objects to the local Repository:
Fig11
GIT_REMOTE_ADD_PRODREPO Job:
The Job does a remote add to the GIT Repo PROD_Repo from the Repository PREPROD_Repo:
Fig12
GIT-COMMIT-ADD Job:
The Job GIT-COMMIT-ADD does a commit on Code and Scheduling Objects Definitions to be promoted into the PROD ENV:
Fig13
GIT_PUSH Job:
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.
Fig14
Fig15
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:
SNOW_GITREQUEST_TICKET_CLOSE Job:
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.
Fig16
Fig17
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:
Fig18
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.
Fig19
Conditional Dependencies are defined from the GIT Push Steps called PUSHSUCCEDDED and PUSHFAILED.
Fig20
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:
Fig21
Fig22
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.
Start a Conversation with Us
We’re here to help you find the right solutions and support you in achieving your business goals.