So,
fxa-content-server
fxa-auth-server
fxa-auth-db-mysql
fxa-customs-server
fxa-oauth-server
fxa-profile-server
**use tags**, set by a grunt task with `grunt version`.
The other repos use, ... oh wait, there are no other top-level repos that we
ship to production.
content, auth, auth-db, customs additionally cut a branch at the same time,
which isn't necessary most releases, but simply follows a practice we have
used from the beginning.
fxa-auth-mailer is an npm+git-url dependency pulled into fxa-auth-server. It
targets #master, but shrinkwrap controls which actual sha is used. This also
controls the git sha of fxa-content-server-l10n.
The production version of fxa-content-experiments, by design, and by
agreement, is controlled by this file[1] in fxa-content-server. The
contents of that file determine what version is pulled at runtime. Commits
to that file are controlled by the standard PR and review process for
fxa-content-server. I emphasize that this process was chosen to give the
owners of fxa-content-server flexibility and control over which experiments
would go live, while ensuring that random commits on master or other
branches did not go immediately to production.
I think "unexpected sha was initially slated to go to production" is a
mischaracterization. Whatever we choose is what will go to production and no
choice had been made yet. You misinterpreted my response.
However the root problem in this area is that fxa-content-server-l10n
doesn't
appear to be smoothly forward-compatible. Why shouldn't HEAD of l10n always
contain reasonable translations for strings in our code?
John
[1]
https://github.com/mozilla/fxa-content-server/blob/master/server/config/production-experiments.json
On 10/16/15 02:23, Shane Tomlinson wrote:
Last week we had a mixup with the fxa-content-server-l10n repo when
cutting train 47. The fxa-content-server-l10n repo has no formal
tagging procedure and an unexpected sha was initially slated to go to
production. While investigating whether the unexpected sha could be
used in production, I saw the fxa-auth-mailer uses neither tags nor
branches to indicate which sha is used for a particular train. I had
to ask jrgm which auth-mailer sha was going to be used in production.
Today Ryan Kelly questioned whether [1] could be merged into the
fxa-content-server-experiments repo or whether he should wait until
Monday, stating "I don't want to merge it last thing on a Friday
evening and have the change go straight to production - let's deal
with it on Monday when prepping the cut for train-48."
Some repos, like the experiments repo, use branches. Some repos use
tags. Some repos tag/branch for every train. Other repos are only
branched/tagged when the code updates, making me ask "is <train-XXX>,
that is 3 trains behind, the code that is really in production, or has
somebody forgotten to branch/tag?". Point release tags/branches are
only done on the repo that causes the point release.
I find this lack of a unified process extremely confusing, and more
than likely a contributing factor to week's snafu and Ryan's
confusion. It should be easy for us to get to a better place with a
unified process that is used across all repos.
After looking across a sample of repos, tags appear to be the most
popular way of marking a particular train's sha.
My strawman proposal - *all* backend/server repos are tagged *every*
major train. Repos do not need to be tagged at the same time, but they
must be tagged by time the train goes to production, even if the code
has not changed. Client side libraries that are included via bower
would be exempt since the repos in which they are included specify the
exact sha/version.
The process could largely be automated by individual repo "owners",
and at a minimum, verification could be handled by a script with a
list of repos to check.
Thoughts?
Shane
-----------------------------
[1] - https://github.com/mozilla/fxa-content-experiments/pull/25
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
