HWA-GIT-SNOW Integration: Application Code Promotion and Scheduling Objects Promotion Orchestration

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 :

Fig 1

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 .

Fig 2

EXTRACT_REQUEST_TKTNO_GITREQUEST Job :

​This Job would be a Unix Job which would Extract the Ticket Number from the Output File /tmp/requestsgitcodeprmoutput . ​

Fig 3

EXTRACT_REQUEST_SOURCEENV_GITREQUEST Job:
​
This is a Unix Job which would extract the Source Environment from the Output File /tmp/requestsgitcodeprmoutput .

Fig 4

EXTRACT_REQUEST_TARGETENV_GITREQUEST Job:

This is a Unix Job which would extract the Target Environment from the Output File /tmp/requestsgitcodeprmoutput .

Fig 5

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:

Fig 6

GIT-SETCONFIG Job:

This would be a Unix job to set the Global Config for UserName and Email:

Fig 7

​GIT_INIT_2 Job:
​
This job initializes the GIT Repo locally:

Fig 8

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:

Fig 9

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.

Fig 10

GIT_ADD_2 Job:

The Job GIT_ADD adds all application Code+Full Dump of HWA Scheduling Objects to the local Repository:

Fig 11

GIT_REMOTE_ADD_PRODREPO Job:

The Job does a remote add to the GIT Repo PROD_Repo from the Repository PREPROD_Repo:

Fig 12

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:

Fig 13

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.

Fig 14

Fig 15

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.

Fig 16

Fig 17

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:

Fig 18

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 .

Fig 19

Conditional Dependencies are defined from the GIT Push Steps called PUSHSUCCEDDED and PUSHFAILED.

Fig 20

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:

Fig 21

Fig 22

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 suppressed.
 
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.

---

Authors Bio

​Sriram V, ​Senior Technical Lead
​
Sriram is working with Workload Automation for the last 12+ years. Started out as a Scheduler, later as an Administrator, SME and India SME of the Product. He has been part of the Product Team in the last few years supporting Workload Automation on SaaS before moving to the Lab Services and Tech Sales of WA.