SDLC Process Flow
- Initial development in local
- Merge into DEV for final development, unit testing and integration checks
- Deploy to UAT for full user validation and signoff
- Deploy to Production
PL/SQL Script Development & Management
All changes, including scripts are required to follow established SDLC processes, whether a one-time fix or part of a development request.
- The SQL code file will be attached to the Jira.
- The SQL code file will contain a decription of the script's intended purpose and specific actions as well as the Jira number. This is to be located at the top of the script.
- The SQL script will be checked into subversion.
- Like any other development object, the script will folow the above described SDLC process. A script will not be deployed to PRD until user signoff has been secured.
- Execution of the script in PRD will occur one of two ways:
- If the script is part of a larger development request, it will be executed by the CM following the successful build of the environment.
- Today: If the script is a one-time requirement for the purpose of resolving a data issue, a request will be submitted to the DBAs to execute the script in production at a time when all users are off the system.
In Process: If the script is a one-time requirement for the purpose of resolving a data issue, an ad-hoc job request will be submitted to Scheduling to execute (from Control-M command line) the shell script in KFS, passing the name of the SQL script file as a parameter.
- The resulting actions of the script in PRD must be validated by the requestor prior to resolving the Jira.
Script Naming Conventions
<unique sequential #> - <Jira #> - <SIT #>.sql (the ServiceIT (SIT) ticket number is optional since there may not be one tied to the Jira)
This convention by its nature identifies the following important pieces of information:
- The order in which scripts should be executed based on the order in which they were introduced into the environment (identified by the starting sequence #) This is most relevant to the CM at build time
- whether the script is intended for KR or KFS (identified by the prefix of the Jira - KRICE or KFS) Note: If a script is needed to update data in the Rice (KR) schema for a KFS JIRA, simply replace the "KFS" portion of the JIRA number in the script name with "RICE". This will identify it as tied to the KFS JIRA but intended execution is against the KR schema. (Example: 088-RICE-1588-Remove_POA_FO_Force_Action.sql)
- The Jira number of the development effort
- The ServiceIT ticket if applicable
Additionally, as shown by the image below of the svn repository, the script’s author and the date and time it was checked into svn are also visible.
Emergency Script Changes:
- An emergency fix that involves the execution of a SQL script will follow that same process as an other emergency change. This process is currently being refined based on the evolution of our system change management process but in a nutshell the emergency fix involves merging the change (java, PL/SQL, etc.) into the HotFix branch for introduction into a refreshed SUP. The successful fix will then be introduced into the rest of the environments through the normal process, in a compressed timeframe. All documentation supporting the fix is still required as well as reporter signoff.
The SDLC and Jira link
The integration between JIRA and Jenkins facilitates our change management process, which is based on monthly planned releases of minor improvements and bug fixes. The use of status fields in JIRA is designed to provide a clear picture of where in the SDLC process a particular JIRA is (requirements gathering, design, development, test, or complete). When used as defined, JIra is the complete container of a development activity. The Requirements, specifications, test plans, deployment documentation, all relevant signoffs, as well as the complete interaction history between all responsible parties can be either stored on or linked to the Jira(s).