Add continuous deployment for the master branch?

[almet]

@ckarlof pointed out it would be interesting to have the master branch of readinglist always deployed on the dev instance.

We've had a quick discussion about that previously and it seems we agreed to do minor DEV releases in between "real" (e.g. to be deployed) releases. I believe this means we won't have continuous deployment, but I kinda like the idea, I just don't know how practicable it is (Maybe @ckarlof you can point out how we do for some other projects?)

note: we just split the readinglist into different repositories (readinglist, cliquet, kinto, and as a result we're waiting on a first tag to deploy everything (should happen shortly). You can read more about what is what is what

[ckarlof]

Maybe @ckarlof you can point out how we do for some other projects?

FxA has single box deployments which contain all the subservices needed to run FxA, as well as some reliers, e.g., Sync and 123done. These deployments are currently handled by the fxa-dev project. Each single box deployment is configurable to how often it is updated. For example, we have a "stable" one which manually updated after each production release (it mirrors the code on prod), and we have a "latest" one which runs master on each subservice. It simply polls github to keep up with master, and when it detects a change, it re-installs itself. The "latest" box is pretty reliable, although occasionally updates blow up. :)

We should consider adding RL to the services on fxa-dev. In that sense, fxa-dev would be more like "identity-dev", a one stop box with all the identity services on it, all configured to use each other. That would also create more consistency around how the client side teams develop against our services.

fxa-dev uses ansible, and integrating RL would simply require adding each of its services to the roles here: https://github.com/mozilla/fxa-dev/tree/master/roles

You might try a crack at it, but @dannycoates and @vladikoff are also available to help answer questions and get RL integrated.

[Natim]

I like the idea of having rules to automate deployement. Also would it make sense to use OPS rules to do so? I was thinking of a dev configuration files that would deploy a new version. This will let you benefit from OPS rules as well as helping OPS to have up-to-date configurations.

@ckarlof Is there a reason why you didn't used OPS puppet rules for FxA?

[ckarlof]

@ckarlof Is there a reason why you didn't used OPS puppet rules for FxA?

fxa-dev predates when using our prod setup for dev was viable. We'll probably start using a prod clone in dev in the near future.