Customer repo manifests: A way to use the same branch management as R&D

Vanilla Forums
Vanilla Forums
edited June 2018 in Dev & Ops

As we move to the new hosting environment (with clusters numbered > 1000) we're going to have some new deploy tools available.

The biggest change to Services is that customer repos will have a 'manifest' that defines what sites should use what branches of their customer repo.

This means we're no longer tied to a 'staging' vs 'master' paradigm. Whatever site=>branch mapping is defined in the manifest (on the master branch) is what will deploy to the clusters. We can do customer release branches! No more permanent code divergence, or trying to juggle where we merge PRs.

Example: We create branches release/A and release/B on the Zenimax repo. We can assign release/A to their production site and release/B to their staging site. When it's ready, we can then also assign release/B to production and delete release/A. This matches how we do releases of our core product.

Tim has set up a sample manifest on the PennyArcade repo here: https://github.com/vanillaforums/pennyarcade/blob/master/deploy.json

Note it uses the console SiteID to define what repo branch should be used.

The goal for this month is to get this set up on all our customer repos. This is something I'd like to see @patrick_kelly and @Isis doing for any customers currently onboarding (or otherwise receiving services). Then we'll get @franciscaisse and @danim to get the rest of them. It should be fairly straightforward in that we're currently using branches named 'staging' (or 'stage') and 'master' for 99% of customers.

This is also an excellent time to press ahead with separating customers from the 'clients' repo more aggressively. If you can spare a minute to knock out a few and feel comfortable doing that, please do. I'm happy to answer questions about the process.

Comments

  • Unknown
    Unknown

    Just to be clear in the example above the deploy.json file would look like this:

    {
    "groups": [ 
        {
            "name": "production",
            "sites": [
                6027239,
                6028165
            ],
            "branch": "release/A"
        }, 
        {
            "name": "stage",
            "sites": [
                6028163
            ],
            "branch": "release/B"
        },
    ]
}

    But after release/B is approved by the client it would look like this:

    {
    "groups": [ 
        {
            "name": "production",
            "sites": [
                6027239,
                6028165
            ],
            "branch": "release/B"
        }, 
        {
            "name": "stage",
            "sites": [
                6028163
            ],
            "branch": "release/C"
        },
    ]
}
  • Unknown
    Unknown

    Also, what is the naming convention we want to use? Is it release/* ? And if so, what would * be, something generic like the date or the quarter?

  • Unknown
    Unknown

    One more question. I made a PR for the first one I did (https://github.com/vanillaforums/arenanet/pull/42). Should we just merge them directly into master going forward?

  • Vanilla Forums
    Vanilla Forums

    Yes, use release/*.

    I suggest using a semantic version number by default, but a customer may use whatever scheme makes sense to everyone working on it.

  • Vanilla Forums
    Vanilla Forums

    @patrick_kelly said:
    One more question. I made a PR for the first one I did (https://github.com/vanillaforums/arenanet/pull/42). Should we just merge them directly into master going forward?

    No, continue using PRs.

Categories