Branch workflow clarification for auto deployement

@alexandre I discuss with @plup & we need to clarify the automatized deployment of our branches here.

Here's the current workflow:

master
\- alpha -> manually published on alpha (currently awaiting auto dep & database cleaning)
\- staging -> manually published on test-paris & test-nantes
\- smart-toulouse -> manually published, few customization lines to change before publish
\- other branches, merged on staging by MR, manually published before merge on test-paris for validation purpose

Here's what we can do:

master -> only validated features, auto published on test-paris, test-nantes
\- alpha -> "locked" version, auto published on alpha on MR from master
\- smart-toulouse -> "locked" version, auto published on smart-toulouse on MR from master, manual customization check (logo, title) during MR.
\- staging -> bleeding edge version, target of MR, auto published on staging.test-paris.happy-dev.fr on MR from other branches for validation
\- other branches -> well, no idea for an auto deploy here, as we can have multiple MR at the same time, that lead to validation after MR on staging?

I believe that this way could allow us, in a near future, to auto-customize alpha & smart-toulouse or any other client with placeholder on our code?

I set master on test-paris & test-nantes because these instances are pre-production with features that are already functional & validated but new to users. After all, if you want to customize a new client, you'll be based on this step.

@alexandre Are you OK with that?

changed milestone to %Projects part I

@jbpasquier, @plup: Thanks for the clear summary.

What do you mean by with placeholder on our code??

I find it a bit weird that master is not the production branch, as alpha is in the schema, but I tend to think that what makes sense for you is best schema. So if you guys think that is what makes sense, I am all for that.

Who can merge MR into master? Who can merge master into alpha?

Last question: today we have one specific app, that is SMart Toulouse. Tomorrow, we quickly have a hundred. How do we keep their code base synchronized with the latest version of master?

By Alexandre on 2019-11-21T22:15:05 (imported from GitLab project)

I'm separating your question to get different threads on each point.

What do you mean by with placeholder on our code??

For now, app customization is a name + a logo. By the way, that's enough to use variables for that.

Not a long term solution. Just a short run suggestion.

I find it a bit weird that master is not the production branch, as alpha is in the schema, but I tend to think that what makes sense for you is best schema. So if you guys think that is what makes sense, I am all for that.

I see it more as master is a production branch, everything on is stable & working.

But I see Alpha, as for Smart Toulouse, as a client. As it, it'll need an update to get to the latest stable version.

Who can merge MR into master? Who can merge master into alpha?

Good question.

I tend to say staging -> master, only you, definitive validation of a shipment.

For master -> alpha, as you validated shipment on master already, we can stand for a more case-by-case, if it does not need a migration & it's only frontend devs on, no need for another validation.

Last question: today we have one specific app, that is SMart Toulouse. Tomorrow, we quickly have a hundred. How do we keep their code base synchronized with the latest version of master?

I don't have any answer for hundred. By the way, I may not get the real difference between each of these clients. If it's a logo + a name + some will have, let say, Circles, others will not ; then from front-end side, we can handle all of these with placeholder variables that'll contain that. It does not answer for server-side updates & prosody's configuration, but that's not the subject here.

OK. How do we do it now then? We change the values of the name and the logo in the code manually?

By Alexandre on 2019-11-21T22:24:52 (imported from GitLab project)

Yes, I understand the logic. Makes sense to me.

By Alexandre on 2019-11-21T22:25:42 (imported from GitLab project)

OK.

staging -> master: how would that work concretely. Soon someone with no technical knowledge will take my position as product owner here. He or she needs to be able to:

1. test a feature to validate it
2. press a button that does the merge for him/her

I guess my question is: can we do something more fine grained than merging the whole staging into master? Can we say: I validated that feature, meaning that set of commits, and I merge that into master?

By Alexandre on 2019-11-21T22:33:47 (imported from GitLab project)

I would tend to put them on the "config.json", that is now a variable on gitlab, per project.

As is, no need to code change anything.

You want to update a client app -> Do an MR, everything else will be automatized. I bet we could automatize everything, but I don't really like it, as we still have few clients, human interaction will give us the opportunity to check every step.

@jbpasquier: I guess placeholders are enough at least to start with. Later on the code base will diverge more and more.

Let's assume placeholders respond to everybody's needs for now. How do we deploy them then? Meaning, how does a new version of master makes in into SMart Toulouse and the other 99 customized platforms?

By Alexandre on 2019-11-21T22:36:41 (imported from GitLab project)

I gave that idea but by branch instead of set of commits (anyway, that's the same) during our call, @plup told me that he'll look on possibilities.

For a simple usage, as now, I can manage to pipe only one (or few) MR to staging & ask a validation for them, leaving eventual other MR in a waiting state.

Clear for me. Thanks

By Alexandre on 2019-11-21T22:39:18 (imported from GitLab project)

That would indeed be ideal I think. Thus testing process is clear and modular.

By Alexandre on 2019-11-21T22:40:21 (imported from GitLab project)

Let do this as an user story.

You're Bob a client with a Sib App.

You have a new Awesome feature on master and you want it on Bob App.

What you have to do: Make an MR from master -> bob-app. Everything else will be handled by what @plup did. :)

If I change the logo url & client name to be some variable that are on the config, @plup pipeline will take them & build the client app with them then deploy it.

Easy, no? :)

As I said, we can get ride of the MR step & auto-build-with-vars-and-deploy later, for now I don't think that's a good idea.

OK clear enough for now.

@sylvain: Happy with the overall discussion here?

By Alexandre on 2019-11-22T10:57:03 (imported from GitLab project)

Not sure. I think we should have a call to make sure we're all on the same page on where we're going.

I'd say that either people use the official version of the app, and their plugged directly on master, or they use their own, and they have their own repo.

As for branches, I'd go more for a feature->dev->master, with a preproduction server synchronized on dev.

But I'm happy to challenge that with your ideas. I think it's worth a call, let me know when it's the right time for you.

Call could be useful, yes, as what you said is what's described with "dev" instead of "staging" on branch name. ;-)

Let's do this on monday or tuesday.

Yes the branch name doesn't matter, but the difference is mainly in the fact that I don't think each installation of the app should have their own branch. And maybe also on the validation process.

Monday we'll be in the train, Tuesday is probably easier.