Discovery: Opportunities to Reduce Content Build's Time to Deploy Content Time

[gracekretschmer-metrostar]

User Story or Problem Statement

OCTO has a commitment to keep content build's time to deploy content below 60 minutes through an SLA and content build's time in averaging between 58-60 minutes, so CMS team needs to find opportunities to reduce the time to keep with the SLA.

Description or Additional Context

Something that I have been keeping an eye on that I think needs to be addressed: content build’s time to deploy content has been creeping up to be, on average, over 60 minutes per release (datadog dashboard). This is a problem because OCTO has a SLA with (I think) VHA that content build’s time to deploy content can’t exceed 60 minutes. Previously, we had taken the approach to allow content build to limp along without putting much work into it because AP was working on getting Next Build into production. But now, it’s not clear to me if/when Next Build will go into production, so I wanted to re-raise getting more attention on improving Content Build’s time to deploy.

Observations:

Since 9/4/2024, content build's average times:

• Past 2 days average: 59.36
• Past 1 week average: 58.52
• Past 1 month average: 55.48
• Past 2 month average: 55.25

There was a clear spike in time starting about two weeks ago.

Acceptance Criteria

• [ ] Identified small opportunities to reduce content build's time by five minutes.
• [ ] Idenitified large opportunities to reduce content build's time by more than 10 minutes.
• [ ] All opportunities are documented in Github and discussed with the VA PO about priorities.

[gracekretschmer-metrostar]

@EWashb has given us feedback that OCTO is okay with exceeding the 60 minute SLA requirement and the priority should continue to be to get Next Build into production.