Production Installations

Production installation requests for Banner application code are submitted through Footprints by setting the status of the ticket to "Awaiting Install". Depending on the impact, pending requests may require forwarding to the Change Management committee for review, and/or postponement until a suitable maintenance window (usually Tuesday nights/Wednesday mornings).

Objects to be installed in the production environment are usually reviewed before installation for the following:

  • They should comply with development standards
  • They should address all issues described in the related ticket (to ensure that the problem or issue is resolved the first time)
  • They should not address issues not described in the ticket (to ensure that all changes are documented and made known to the user)
  • They should be thoroughly tested by the person or department that requested them
  • If the developer is also an installer, it is desirable that the code review and installation be performed by a different installer (to ensure knowledge transfer, as well as integrity of the code review process)

Requests may be sent back to the developer if standards are not met or if there are significant differences in the code when compared with the ticket narrative.

The person or department who requested the change must acknowledge that they tested the process before it can be installed. The analyst or his/her designee is responsible for obtaining user approval for the installation of any new process; it is generally not the responsibility of the installer.

Code Review

Source code is required for objects being installed into production. Developers often create packages, procedures, and functions in TEST using Toad or SQL Developer. If they request production installation of such an object, insist that they create a source file from the object, that they copy it to the appropriate location in the Banner code tree and create a link for it in $BANNER_LINKS, and that they test the source file by installing the object into TEST with it.

When installing updates to an already existing source file:

  1. Login to the production Banner job server.
  2. Use sudo or xsu to become the banner user.
  3. Navigate to the code tree directory where the source file will be installed.

  4. Run testdiff <filename> to identify the changes that were made in the new version of the object.

  5. Review the differences to ensure that changes address the issues in the related ticket.

What to check: We do not have any explicit standards related to indentation, use of lower-case vs. mixed-case vs. upper-case, or naming variables. However, if you find yourself regularly having to debug code, feel free to modify the TEST versions of code files to match whatever indentation, case usage, variable naming, and/or commenting conventions that make the debugging easier for you, and to insist that these conventions remain in the source file as it is promoted to production.

Audit Trail: Whether a new object or a modified object, a Audit Trail or Comment Box should be created or updated. Many of the older objects may not have an Audit Trail or Comment Box.

Here is an example of a Audit Trail or Comment Box: 

     /*************************************************************************************************************************/
     /*  Date          Ticket   Developer       Description of Change                                                         */
     /*  01-JAN-2018   111111   Bob Smith       Program modified to pick up the new employee codes for Priority Health        */
     /*  02-FEB-2018   222222   John Doe        Program modified to fix Bob's change                                          */
     /*************************************************************************************************************************/

User approval: Ideally, the user who requested the change is the primary contact in the Footprints ticket, and has updated the ticket themselves to state that the change has been tested and approved for production installation. However, if the user sends the developer an email stating that they have tested the change and approved it for installation, it is acceptable for the developer to copy and paste that email into the ticket, as long as the user is also the primary contact or a CC on the ticket.