Meeting Date
Information that is gathered and tabulated in this page will be reviewed in the weekly DMS/SRDP Meeting:
October 21, 2020 1PM EDT / 11AM MDT (postponed from Oct 7, 2020)
Objectives of this Review/Retrospective
- To review processes used in preparation for and during the RH7 (and associated software) upgrade to the VLASS dev/test/prod environments.
- To improve processes as we prepare for future similar work.
- To encourage everyone on the team to engage in process improvement
- To review what went well and what did not
- To identify processes and practices that should either change or be discontinued
- To establish concrete steps to address each item reviewed
Scope of this Review/Retrospective
- Overall upgrade process
- Communication
- Post-upgrade bug identification
- Ongoing development during upgrade.
- Processes used for infrastructure deployment and maintenance in dev, test, and production
Roses and Thorns Retrospective Approach
- Roses: What is working?
- Thorns: What is not working?
- Buds: What opportunities can we explore?
- Fertilizer: Improvements on existing processes, support for new idea
- The list has been structured using a "Roses and Thorns" approach
- The document above is below, ready for comments and edits.
- Everyone on the team is encouraged to make edits directly, please forward this request to your team members and leads
- The edited document will be discussed and reviewed in the weekly DMS/SRDP meeting on October 7, 2020
Outcome
There is no pass/fail criteria. An action plan will be incorporated into the document following the meeting and the Project Manager will track and follow up action items.
| ID | Roses | Thorns | Buds | Fertilizer |
| MG-1 | What went well? | What could have gone better? | What opportunities can we explore? | Improvements on existing processes, support for new ideas. |
| JK-1 | Staged testing and rollout yielded are relatively painless transition from the user perspective. | |||
| JK-2 | Testing coordination could have been better. | We could reuse more of the SRDP process even though this was a mostly internal effort, could use a test plan in advance | There is a balance to be struck between planning and doing. Do we think we got that correct this time around? | |
| JK-3 | A lot of cleanup and transition to CIS supported infrastructure was accomplished. | Effort required was greater than anticipated. | Was there scope creep with this effort? Were we intentional about allowing it? | |
| ML-1 | Reconfiguration of profiles in the production areas resulted in a more logical test/production directory structure. | Communication of this change to the operations team needed to be better. | Could look into ways to improve communications with entire Ops+DA team (both sites) for issues affecting SRDP Ops. | |
| SW-1 | Process was made more complicated by 'overloaded' development system. | We could split the development system up into two (or more) systems, focused on specific projects. | ||
| SW-2 | Many services were very out of date, bringing them up to date took longer than anticipated. | We could factor service updates into our schedule on a periodic basis. | ||
| SW-3 | SSA software is fairly well decoupled from its configuration and OS, adapting to changes in both was much easier than it could have been. | |||
| SW-4 | A number of the CIS processes/policies that should be standardized across the sites are not, and are not documented. | |||
| SW-5 | Several of our systems use very old frameworks that tie us to old versions of essential services. | |||