This page briefly describes our strategy for instance management, including the purpose for each instance, refresh schedules for each instance, and a development pipeline for projects moving between instances.
Production instances
Main environment used by the campus community.
- Names: CCHIPRD, HCHIPRD
- Refresh schedule: n/a
Staging instances
Troubleshooting and reporting outside of PRD. Also used for comparing projects before go-live.
- Names: CBCHISTG, HBCHISTG
- Refresh schedule: weekly
Testing instances
User acceptance testing; no active development.
- Names: CBCHITST, HBCHITST
- Refresh schedule: major maintenance pack (roughly quarterly)
Development instances
Development and retrofits by internal technicians and outside vendors.
- Names: CACHIDVL, CBCHIPRJ, HACHIDVL, HBCHIPRJ
- Refresh schedule: alternating DVL/PRJ on major maintenance packs (roughly semi-annual)
Note, during the ongoing CHRS project, DVL instances have typically been frozen, so our development primary instances have been in PRJ.
Training instances
Staff training environment.
- Names: CACHITRN, HACHITRN
- Refresh schedule: no set schedule
Maintenance Packs
A maintenance pack (MP) is a CSU-standard update released by the Chancellor's Office (CO). Each MP has a unique identifier such as CSMP 17.01, which indicates the platform, major version number, and minor version number.
Major maintenance packs, for example version 18.xx, tend to release on both CS and HR.
Minor maintenance packs, for example version xx.01, may release on just CS, just HR, or both.
Primary/Secondary Dev Instance
DVL and PRJ are both development environments, but they will alternate between primary and secondary.
A primary dev instance should have the latest maintenance pack installed. This instance should be used for retrofits, such as PUM compatibility mods, and can also become the default location for active development projects.
A secondary dev instance should have the previous maintenance pack installed. This instance can be used for long-term projects needing 3-6 months in development.
When the CO releases a major maintenance pack, we will do the following:
- Switch primary/secondary dev instances
- Refresh the new primary dev instance (either PRJ or DVL)
- Refresh the testing instance (TST)
If retrofits are needed for the new MP, they should be completed before any new development starts.
Development Pipeline
Projects that require development by internal technicians or outside vendors should complete all development work in the primary dev environment (either PRJ or DVL).
A project that is ready for user acceptance testing can be migrated to the testing environment (TST). This migration can be completed using a database copy or a file copy.
A project that has finished user acceptance testing can be migrated to the staging environment (STG). This migration must be completed as a file copy, because that is the mechanism used in production; this offers technicians a chance to perform a comparison between TST and STG to make sure that the project migrated without detectable errors.
Projects can be migrated into the production environment (PRD) via a Chancellor's Office Migration Request (COMR). Please note, this process requires project documentation such as migration instructions and impact analysis, and the CO team requires a minimum lead time.
Naming Convention
Instance names generally follow the convention of <prefix> <org> <suffix>.
For example, CCHIPRD has a prefix of C, a campus of CHI, and a suffix of PRD.
Example prefixes in alphabetical order:
- C, CA, CB: Campus Solutions (CS)
- F, FA, FB: Finance
- H, HA, HB: Human Resources (HR)
Example orgs in alphabetical order:
- CFS: Common Financial System
- CHI: Chico
Example suffixes in alphabetical order:
- DVL: development
- PRD: production
- PRJ: project
- STG: staging
- TRN: training
- TST: testing