Non-Java Code Software Publishing Procedures (including SEED/USEED)#
Notes: The scripts used in these procedures rely on the user having the mapping of the P: drive to the \\HLC\DFS directory.
The SQL Path in the registry must include: P:\NextGen\QA_Backend\INTERNAL_SCRIPTS;P:\NextGen\QA_Backend for this to work.
1. Seed Pulls are done with the Java builds and no longer required as part of this process.
2. QA must be informed that this process is about to be done as the QA Database is now the master for counts, etc. and is updated during this process. At time of writing this master database is QADB02.lvmdbs2.
Note: From here on, all references to the QA database will refer to QADB02.lvmdbs2.
THINGS TO WATCH OUT FOR!#
- secured server code is delivered in “plb” files, source is in “psql” files
3. Update P2K_SMCV function in PD to have the same version as of the latest QA EAR build and Publish code.
4. Review the items in each developer’s publishing folder to ensure they have supplied all necessary items (specs and bodies together in one file, etc.) and that items are named following HLC standards.
- Move all published software & documents (but NOT zip files or subdirectories) from the Developer’s publish directory over to the P:\NextGen\Pulling\Z directory.
** P2K_PMSEC should be the only package published as separate Spec and Body and that is for wrapping purposes.
5. Search for ‘EDITIONABLE’ at the start of all released code and remove it for now.
6. Correct Case so the ALL file names are Upper and all extensions are lower. (I use a freeware tool that can be downloaded from http://www.febooti.com/products/filetweak/members/case/
).
- Check inside any scripts to ensure any subscripts, log files, etc. ae specified in the correct case.
7. Flip Backend, Windward, etc. closed defects from 4-PD Closed to 6-In QA with http://www.highlinecorp.com/ccare/intranet/defectMassUpdateSearch.cfm and report the counts of defects flipped to QA staff (send email).
8. If any of the published items have the extension .psql then they must be “wrapped” as they are security code that customers should not see. To do this execute the command file ~DIR_WRAP.cmd from the P:\NextGen\QA_Backend\Internal_Scripts directory to create a file called ~wrap.cmd in the P:\NextGen\Pulling\Z directory.
- Modify the lines in this file to be like the sample commented out line. I.e. if P2K_PMSEC_BODY.psql is in the file it should be modified to look like:
WRAP INAME=P2K_PMSEC_BODY.PSQL
- Run ~wrap.cmd to create the .plb files in addition to the .psql files.
9. Execute the command file “~DIR_P_Z.cmd” from P:\NextGen\QA_Backend\INTERNAL_SCRIPTS to create the ~UPDATE.txt script in P:\ NextGen\Pulling\Z
- Add “@” at the beginning of all the script lines in the file
- Remove any lines that are for backport or custom code (or for wrapped code)
- Copy most files in P:\ NextGen\Pulling\Z to P:\ NextGen\QA_Backend except for documents (.doc, .pdf, etc.) and any Oracle Reports or Windward Templates. Include any SEED% files.
10. In SQL Plus, Run @~UPDATE QA Database pswd from P:\NextGen\QA_Backend\INTERNAL_SCRIPTS to update the QA database with the code in the ~UPDATE.txt temporary script file
- Check for any compile errors in the TEMP_DDL_nnnnn.log files
- Check for any blatant errors in ~UPDATE_QAdatabase.log, ~UPDATE0_QAdatabase.log and ~UPDATE1_QAdatabase.log log files
- Check for any compile errors in ~COMPILE_ERRORS_QAdatabase.txt in your working directory.
- ***Resolve any other compile errors before moving on
- Note: If you have loaded any database changes (DDL_yymmdd.tab files), then you must generate the triggers
- In SQL Plus, Run @DB_GENERATE_MONITOR_TRIGGERS to update the master QA database with the triggers.
11. This Step is currently NOT to be done - Check the script ~UPDATE_ALL_QA.sql in the P:\ePersonality\QA_Backend\INTERNAL_SCRIPTS folder to ensure it is pointing to those QA databases that are to be updated/kept up to date with the latest backend code. If there is any core system code or DB Scripts to be loaded the Application instances to these data bases must be stopped.
12. This Step is currently NOT to be done - In SQL Plus, Run @~UPDATE_ALL_QA.sql to update the QA database(s) with the code in the ~UPDATE.TXT temporary script file
- check for any compile errors in ~COMPILE_ERRORS_xxxx.txt and ~UPDATE_xxxx.txt log files on your working directory.
- ***Resolve any compile errors before moving on
13. In SQL Plus, Run @PRINT_DB_OBJECTS_CREATED.sql script on the master QA database to get a list of the new server code that was just added that had not been there before.
- Update the LOAD_SERVER_CODE.sql script in P:\NextGen\Pulling\Z for new server code from ‘PRINT_DB_OBJECTS_CREATED.lst’ log file. Add lines (in alphabetical order) for ALL new code that was created with today’s date as a comment.
- Check packages for elimination of Spec/Body
- LOAD_SERVER_CODE.sql
- P:\NextGen\5.0.BackEnd\DB_Code
14. In SQL Plus, Run @DB_AUDIT_DATABASE_DB12.sql script on the master QA database to get the database counts
- Update the 5.00_COUNTS.txt file in P:\NextGen\Pulling\Z with the database counts from ‘db_audit_database_DB12.log’ file.
- review the missing, extra, and foreign sections to see if there is anything out of the ordinary.
15. In SQL Plus, Run @CREATE_OBJECT_FILE.sql script on the master QA database to create the comma delimited file that gives the object names that are in the current software version.
16. Copy all of the files in P:\NexGen\Pulling\Z to P:\NextGen\Pulling\~Release_staging
- Copy the updated 5.00_COUNTS.TXT to P:\NextGen\QA_Backend
- Copy the updated LOAD_SERVER_CODE.SQL to P:\NextGen\QA_Backend
17. Rename the P:\NextGen\Pulling\Z folder to the P:\NextGen\Pulling\Z_YYYYMMDD (where ‘YYYYMMDD’ is the date of release)
- Move this folder to the P:\NextGen\Pulling\Z_Folders folder. Create an empty P:\NextGen\Pulling\Z folder.
18. Move the contents of P:\NextGen\Pulling\Release_staging to their proper homes in the P:\NextGen.
Change the sort to be by type for easiest dispersal (delete the ~update.txt, ~wrap.cmd):
| FILES | RELEASE TO.... |
| .ctl | P:\NextGen\5.0.BackEnd\Scripts\Keep or P:\NextGen\5.0.BackEnd\CONVERSION_CTL_FILES depending on their usage |
| .csv | to ??? |
| .doc | to P:\NextGen\New_Docs & AllDocs (all documents except ERDs should go to both of these) |
| .docx | to P:\NextGen\New_Docs & AllDocs or IF a WW report see below. |
| .xls | to P:\NextGen\New_Docs & AllDocs |
| .xlsx | to P:\NextGen\New_Docs & AllDocs or IF a WW report see below. |
| .plb | to P:\NextGen\5.0.BackEnd\DB_Code |
| .pls | there should not be any anymore |
| .psql | * |
| .rdf | to P:\NextGen\5.0.BackEnd\OracleReports |
| .sql | to P:\NextGen\5.0.BackEnd\Scripts\ * or \DB_Code\* (except SEED_xxxx) depending on what these are for. *needs close inspection |
| .tab | to P:\NextGen\5.0.BackEnd\DB_Structure |
| .txt | to ? |
| .trg | there should not be any anymore |
| .rtf | to Windward Templates area – see WW report section below |
| ERD | to P:\NextGen\ERDS |
| .jpg | to P:\NextGen\OracleReports (these are usually done for YE reports) |
Delete USEED outputs (SEED & EXT) files.
19. Windward Templates can now be .docx and .xlsx files as well as .rtf files BUT .rtf files are being phased out. These have to be copied to numerous places so that QA and PD have the latest to run as well as being positioned to be picked up for the next release.
At time of writing these templates need to be copied to the following locations:
- P:\NextGen\Windward_Templates\5.0 – should not contain any .rtf files. These are for easy access and review only as the NG the WW templates are included in the HLAppResources at shipping time.
- P:\NextGen\Windward_Templates\All – including rtfs – contains all WW templates.
- P:\NextGen\Windward_Templates\Latest – redundant, only contains templates changed recently by type in subfolders.