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. adapting to new OS was minimal, other services not so much. Original intent was to reuse existing versions, inadvertently some critical resources were not available | Was there scope creep with this effort? Were we intentional about allowing it? Be sure all stakeholders are on board, agree on scope, and understand roles and responsibilities. Upgrade to services may have been handled better as a separate effort. | |
| 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 (e.g. PST) use very old frameworks that tie us to old versions of essential services (e.g. MySQL). | |||