Discovery: Should we automate the packaging of the Vets API helm chart

[laineymajor]

Needs refinement Link to slack thread

Problem Statement

The current packaging is manual and needs to be automated. Automated packaging with GHAs is needed to automatically repackage charts.

Tasks

• [x] Locking down the parent helm chart branch
• [x] Require checks and approving review from backend-review-group ^^
• [x] Determine last time the helm charts were edited (how often are the charts edited; is this ticket worth the lift?)
• [x] How can there be stricter quality standards for helm charts?
• [x] Run all of this by the devops cop

Success Metrics

• [ ] ADD SUCCESS METRICS HERE

Acceptance Criteria

• [x] First determine if this work is worth the work...

[LindseySaari]

This will continue into next sprint. @Kshitiz-devops or @flooose, could you please comment with your latest findings

[LindseySaari]

Looking at all the pieces to automate this. Rachal cleaned up the helm packaging scripts.

@Kshitiz-devops looked into the missing directories and will continue to work on GHA for the automated building/packaging. We can use conditional workflows to trigger the chart release

[rmtolmach]

Chris and Kshitiz to meet to discuss.

[flooose]

From a best practice perspective, I think it's worth automating the release process of the helm charts. The Lights team is currently doing the same thing and this gives us an opportunity to align our implementation with theirs, to the extent possible, and get ideas and feedback from them if our implementations have to diverge in some capacities.

I think as a first step, we should update a README (probably in vets-api) that points at the existing documentation in confluence and to links to the relevant branch in vets-api, where the charts are hosted.

Since vets-api is a public repo, we can then use the chart-releaser-action to automate our release process. In the context of this, I would consider any renaming of branches or folders that are involved to see if we want to align ourselves with naming conventions. See the settings for the github action for examples, or get opinions of other members of the platform. We can also use the Helm Charts Best Practices from our confluence to consider changes we might want to make.

There was also some concern about people releasing charts who don't know what they are doing and it seems like there may be a way to limit who gets to run specific actions, such as admins. I still have to explore this a little more.

[laineymajor]

@LindseySaari @RachalCassity to provide feedback on the above comment?

[LindseySaari]

@flooose Great point! I 100% think we should follow any standardized process that the Lights team already has in place. Updating documentation would be a great first step. It seems we should even add some of the deployment related info to the README as well (unless this is sensitive and shouldn't be public facing) If anything we could provide some confluence links that only users with perms can access.

I took a spin through the Helm Chart Best Practices doc and I think we could standardize around a lot of the things mentioned (if we don't already). We can also lock the chart release down with admin perms in the Github settings. All in all, I think the automation should move forward and it's great that other teams are pushing work forward in this same regard, allowing for standardization across the board!

[laineymajor]

Start giving this a spin! @flooose to meet with Patrick Black

[jennb33]

More work needs to be done on this ticket per @flooose, so it is rolling into Sprint 50.

[jennb33]

The Helm charts are moving from Index to Containers (CR) moving forward, and the GitHub pages are going to be deprecated, per @RachalCassity and @Kshitiz-devops Please add more information based on the Discovery that you learned, Kshitiz.

[Kshitiz-devops]

The packaging of helm chart should be automated. Our plan is to use ECR as helm repo which can be used easily for deployment. Once the package of helm chart is automated to ECR the helm chart will be versioned with Semantic versioning which will match with the container version so each helm chart will be deployed with their container version which will be helpful with preview instances in eks.