Create & Present Release Pipeline Architecture Diagram

[damienjburks]

Feature Request

Since we have decided on the way we want to release the artifacts, it's time to start putting together a high level diagram for the pipeline solution.

Requirements are still WIP and are dependant on #333

[damienjburks]

Here is an example architecture diagram, let me know if you have any thoughts on this - @eddie-knight

[eddie-knight]

Reflecting on the tag idea... I don't think this will be as simple as we'd like. Because its a monorepo with many assets, at release time we'll need both the version identifier and the build target

[damienjburks]

Can you expand upon the build target? I'm not following you on that.

[eddie-knight]

Sorry, I meant the directory for the assets we want to be compiling. Like services/storage/object.

[damienjburks]

The build target (or source directory) could be supplied based on the tracking of the commit IDs. Remember what I spoke about having some kind of announcement that tags folks for contributing? If we do that, then we could create some kind of process to enable us to automate a big bulk of it. Here's what I'm thinking we could do:

1. Enforce that folks to squash all of their merge commits prior to merging
2. Take that commit information and create a release page for keeping track of it
3. When we create a tag, we can write something that would pull the list of hashes and the version identifier, pass in the list of commits (or page), and dynamically derive the assets that we'll want to compile for the release, and perform start it.

The problem that I have with this approach is, we'll be releasing only those artifacts that have been modified.

In my mind, all of the artifacts that we have in our project should be compiled and released. So, for every release, we attach some kind of summary page that gives our stakeholders the list of changes. I think this'll keep our system simple while ensuring that we're effectively communicating the deltas across the various different releases.