search

newrelic / nr1-catalog-manager

This project is used by New Relic to manage the collection of open source Nerdpacks that make up the New Relic One Catalog
Apache License 2.0
2 stars 4 forks source link

Define Catalog Manager improvements & next steps #8

Closed jpvajda closed 3 years ago

jpvajda commented 3 years ago

Relates to: https://github.com/newrelic/nr1-catalog-manager/issues/6

General Observation of the Catalog Manager flow

The current process requires a lot of toil. Pulling down the nerdpack, manually testing it, using the nr1-catalog-manager, merging into the nr1-catalog, and then notifying platform services. Breakages at any point require creating a new release of the nerdpack and starting at the beginning.

Quick improvements could be made to test and validate the nerdpack before creating a release, removing the need to do this before adding it to the nr1-catalog. This should also verify that the catalog requirements are met, such as screenshot aspect ratio and size.

After the improvements above, the nr1-catalog-manager could be phased out in favor of the nerdpack itself controlling releases to the nr1-catalog repository.

Another option is to remove the nr1-catalog and the nr1-catalog-manager, allowing each nerdpack to handle its own release process.

Publishing Pain

If the nr1-catalog must stick around to manage the current prod versions of the nerdpacks, then moving it away from git submodules and over to a semantic version based system (think package.json dependencies) will reduce a lot of headaches. Notably avoiding issues around merging a new PR before an older one.

nr1 nerdpack:publish pushes to artifactory, which is 1 global instance for all envs. Enabling it in US is the default behavior. Staging/EU require manual effort to do the same.

Given there's no API built to push apps to EU and Staging so Platform Services has to manually update entries in some system/DB they have access to to push app updates on these environments.

Marking as global ain't easy

The other thing holding up self-service publishing, is marking an app as GLOBAL is done via an API that's only exposed behind CHI VPN So we can't automate that from public GitHub action. This is done when an app is first added to the catalog and it needs to change from an individual owner state to a global state.

Acceptance Criteria

jpvajda commented 3 years ago

@aswanson-nr / @zstix I pulled this feedback out and will schedule a chat with @jbeveland27. This will go in Sprint 2.

jpvajda commented 3 years ago

added some more insights & observations from @jbeveland27

jpvajda commented 3 years ago

Results of our conversation with Justin.

We propose the following workflow:

  1. When an application is updating and versioned, we automatically run App Catalog Update checks on that app's GH repo on build and deployment to main.
  2. If these checks pass, we kick off a PR to the NR1-Catalog repo to update the application's version in the US:Prod.
  3. We then review the PR and merge it in, thus updating the app WITHOUT the use of the catalog manager.
  4. We no longer use the catalog manager to these updates, so we'll want to move this project to either experimental or archived it's currently set to community.
jpvajda commented 3 years ago

@jbeveland27 / @aswanson-nr / @zstix what do you think of the above proposal?

jpvajda commented 3 years ago

Other considerations:

Request from nr1- platform-services