Download

268 views
214 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
268
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Download

  1. 1. Standard: Application Release Checklist Phases: System Development and Demonstration, Production and Deployment Activities: System Development Tasks: Prepare Application Release Checklist, Prepare Application Release Checklist Reference: DFAS System Life Cycle Effective Date: August 24, 2004 DEFENSE FINANCE AND ACCOUNTING SERVICE Application Release Checklist for Program Name Date of Issue and Status: Date checklist is acknowledged as acceptable (mm/dd/yyyy) and whether plan is draft or approved. Also include version number. Issuing organization: Identify the organization issuing this checklist.
  2. 2. Application Release Checklist Requested by ___________________________ Requested Implementation DATE ___________________________ Purpose for this release: Examples: New application, Version of application to correct functional errors, Version of application to enhance functionality, etc. To be completed by the DFAS TSO-CS personnel. Date this Release was Received into DPET Task Queue ___________________________ Received By ___________________________ Assigned to ___________________________ Date Release was executed ___________________________ Executed By ___________________________ Oracle/DB2 Node Name ___________________________ Oracle/DB2 Instance Name ___________________________ Web Server Node Name ___________________________ Forms Server Node Name ___________________________ Web Application URL ___________________________ 2
  3. 3. APPLICATION RELEASE CHECKLIST 1) General Instructions for this Release. Include here AT LEAST the following types of general information and instructions for this application release, if they apply. Include any specific order of creation for the items in this document. Note: Any items or instructions that need to be addressed in this implementation not covered in any of the following paragraphs are to be included here. If there are questions on any items, please call DFAS TSO-CS and ask for clarification or guidance. Target Oracle/DB2 Owning Schema(s) Oracle/DB2 Version minimum, if applicable Server tools needed other than the RDBMS and SQL*Net Oracle Accounts needed other than Oracle Owning Schema(s) Operating System accounts and allocated file space, if needed UTIL directories needed in the database init.ora file Update the links for the following files in their corresponding /bin directory. 1a) Integration Points Used to Serve this Application’s Functionality. Integration points are defined as any usage of a table, view, procedure, or other object not developed and “owned” within this application. Please detail (in text form) all aspects of integration to be used in this environment or in the production environment. This may include the dependency on other applications or processes that are critical to this application’s functionality. 1b) Expected Oracle/DB2 Environment Availability. Detail the hours of usage this environment is needed. For examples: This development environment is needed from Monday thru Friday from 0700 to 1830 hours. Or This production environment is used by interactive users from 0600 to 2000 Indianapolis time. The application batch jobs will run from 2000 to 2330 Indianapolis time. 2) Environment Needed, RDBMS Node Files, CRON, etc. List the directories and files needed on the Oracle/DB2 Server Node. These should be in a "mkdir" script and a "move" script that will include ownership, group and security level setting for each item. These items and master scripts should be in release management and specific parameters set in the top of the files to reflect this version / application environment requested. All files for the environment that 3
  4. 4. specify directories and instance names need to be checked out and edited. These files are then checked in and presented with this ARC. 3) Table Scripts. List the create table scripts for any tables to be used by the application. There should be as many create table scripts as there will be schemas owning tables for the application in production (2 or more for integrated applications, for example). The create syntax must include tablespace names from the attached “Storage Definitions Guidelines” document. Do not include any other storage information. The primary and unique constraint creation should NOT be included in this section. Migratory Instructions. List all tables for your application and indicate the data load for the initial data. If no data is required, simply put N/A. For example: Table Name Data load Comments Table_A xxxx.sql SQL scripts Table_B N/A zero rows Table_C .DAT .CTL SQL*Load Table_D export From <instance><schema> Keep in mind the referential nature of this data, i.e., never migrate children without the parents. Please include all SQL scripts, SQLLOAD control files and their data files, export files, and FTP instructions. All SQL and SQLLOAD need spool and log files specified. Whenever possible, a multi-step migration should be bundled in one or more UNIX KORN shell scripts. Include here any instruction text to define checkpoints in the migration and a description of expected results to be observed. For a small number of rows, you may include a script file with SQL instructions for inserting (include all column designations as well as values). 4) View Scripts. List the create view scripts for any views to be used by the application. There should be as many create view scripts as there will be schemas owning views for the application in production (2 or more for integrated applications, for example). The please use the syntax “create or replace view”, if possible. 5) Sequence Scripts. List the create sequence scripts for any sequences to be used by the application. There should be as many create sequence scripts as there will be schemas owning sequences for the application in production (2 or more for integrated applications, for example). For those tables populated in 3, you must provide a select script for the table.col that are fed by the sequence. 6) Constraint Scripts. List the create constraint scripts for any constraints to be used by the application other than the column “not null” constraints. There should be as many create constraint scripts as there will be schemas owning tables that utilize these constraints for the application in production (2 or more for integrated applications, for example). The constraints should be “named” constraints rather than ones using “system defined” names. Any Primary key 4
  5. 5. or Unique key constraints must include the “using index” clause where index_name = constraint_name. Any Primary key or Unique key constraints must use tablespace name declarations (see attached “Storage Definitions Guidelines). 7) Index Scripts. List the create “non-unique” index scripts for any tables to be used by the application. There should be as many create index scripts as there will be schemas owning indexes for the application in production (2 or more for integrated applications, for example). The create syntax must include tablespace names. The primary and unique constraints should outline any “unique” indexes and should NOT be included in this section (see attached “Storage Definitions Guidelines”). 8) Database Link Scripts. Detail any application usage of database links. Specify if they need to be public or private. 9) Database Jobs. Identify any DBMS jobs to be executed. Provide scripts to submit the job to the database with the required parameters. Make sure the PL/SQL to be executed is included in the package/procedure section of this ARC. 10) Synonym Scripts. List the create synonym scripts for any objects to be used by the application. There should be as many create synonym scripts as there will be schemas owning objects for the application, for example, 2 or more for integrated applications. If possible, please use the syntax “create synonym <owner>.synonym_name for <object_owner>.object_name;” or use the syntax “create public synonym synonym_name for <object_owner>.object_name;”. 11) API Code from Designer. Specify a .sql file that runs a .PKB , .PKS, and a .TRG for each table where api is implemented. This file should be created from the designer field driving API creation for each table. 12) Application Security Scripts. List the create role script and the Object grant scripts for any roles or objects to be used by the application. There should be as many grant scripts as there are object owners used by the application (possibly 2 or more for integrated Oracle applications, for example). There should also be a grant script from SYS for any direct SYS grants needed by the owning application schema. 13) Other Packages, Procedures and Functions. List the create function, package, or procedure scripts for any server code objects to be used by the application. There should be as many create code object scripts as there will be schemas owning this type of object for the application in production (2 or more for integrated Oracle function usage within the application, for example). The please use the syntax “create or replace <object_name>”, if possible. 14) Trigger Code Scripts. Trigger code is primarily generated from Designer APIs. List in this section any triggers generated by Designer but NOT via API. List the create trigger scripts for any triggers to be used by the application tables. There should be as many create trigger scripts as there are table owners used by the application with triggers 5
  6. 6. employed (possibly 2 or more for integrated Oracle applications, for example). The please use the syntax “create or replace trigger”, if possible. 15) Web Forms Application Setup. List all the static html, images, and map files referenced by the application. Please include a move script that will install and set ownership, group, and security level for the items needed. List the Data Access Descriptor (DAD) information including the schema name and type of database connection needed for the application. List any security requirements for the virtual directories and any security access requirements for these directories. 16) Web Enabled Forms Application Setup. (Developer Applications deployed over the Web) List all the forms, reports, icons, etc. required by the application. . Please include a move script that will install and set ownership, group, and security level for the items needed. Include the path and other environment variables needed. Include information about the type of deployment including static or cartridge and also parameters required by these implementations. 17) Replication Setup. List any requirements to perform Oracle Replication against other databases. Specify the SIDs involved, their versions, locations, and frequency. Provided any necessary scripts, jobs, and usernames. 18) Partitioning Setup. List any table or index partitioning requirements. Provide the partitioning scripts and size estimates. 6
  7. 7. APPLICATION RELEASE CHECKLIST APPENDIX A - ACRONYMS Describe the acronyms as they are used in the checklist. APPENDIX B - DEFINITIONS Describe the key terms as they are used in the checklist. APPENDIX C - REFERENCES Provide a complete list of documents referenced in the text of the checklist. Each reference shall contain document number, title, revision number and date. Policy and Regulation: Policies or laws that give rise to the need for this checklist. DFAS Policy and Standards: DFAS policies and standards that give rise to the need for this checklist. Other Life Cycle Documents: Other plans or task descriptions that elaborate details of this checklist. 7

×