Add develop branch to mature development process

[jfversluis]

To allow a test environment, including functional tests, to be deployed, I created a develop branch and made it the default branch.

My idea would be:

• When PR is opened on develop: run simple CI with unit tests
• When PR is opened on master: run CI with unit tests and functional tests by deploying to a test resource group and tear it down afterwards
• On merge: deploy the whole thing to production

Makes sense?

Also, just an FYI to update forks, etc. I have updated the currently opened PRs, but not sure if it has any side-effects. @Jandev @faniereynders @staal-it

[Jandev]

Sounds ok to me.
Where should we assign the PR's to, develop I guess?

Once the features are done you can merge to master?

In a later stage everything should be able to deploy to Production immediately with some feature toggles in place.

[jfversluis]

Yes, just regular Git flow. Everything happens on develop mainly with feature branches and whenever a release to production needs to happen everything is merged to master.

But I'm open to suggestions 😄

[faniereynders]

Maybe Github Flow or even Trunk Based Development would be a simpler approach.

[jfversluis]

So, basically everyone directly on master? Then how would you go about the build pipeline? No differentiation between CI and CD? It will always do a test deploy and functional test run on a PR? Maybe to a staging slot and then swap it whenever everything is green?

[staal-it]

I would go for trunk based development. Run the functional tests during the pr build against a test environment and automatically promote to production whenever everything is green. We do need to make sure we don't write more functional tests then strictly necessary otherwise the build might become to slow.

[faniereynders]

All PRs to be staged built against Master before merging, as one of the pre-checks. Master to be build at any given time a PR is merged to produce a CI release on a dev/test environment.

Given that all unit and integration tests pass, this action could also trigger an automated build pipeline to initiate some SpecFlow tests in that environment.

When all tests are green and good to go, a tag is created (could also be automated) which will trigger a release to production, or maybe staging slot to be swapped if necessary

[Jandev]

Why create tags if every PR should be placed (after tests) immediately to production anyway?

[jfversluis]

OK, OK, I like this approach, I'll just put master back then... :P
But I'm with Jan, what is the added value for the tags?

And @Jandev how would I go about this with the whole ARM and specifically KeyVault thing? Because ideally you would want to create and tear down each time a PR is built, but the KeyVault needs some settings that are put in manually.

[faniereynders]

Well we need a snapshot of production if a bug arises. Otherwise we can just party on master if anything arises, but it won't be a true copy of production so bugs might not be possible to reproduce.

[jfversluis]

Ah, so basically it's just for reference later. Tag the version that is rolled out so you can refer back to it later.

[faniereynders]

Well yeah, so production bugs could be fixed there and merged back to master once tested.

[jfversluis]

Just to start up this discussion again. I'm still searching for the right way here. The develop branch is gone, so just trunk based, fine. But for building and releasing I'm wondering what is the right approach here.

Calling @faniereynders @Jandev and @staal-it

Ideally, what I want to do is:

• PR is opened with build validation, unit tests, etc.
• PR is accepted
• A build is triggered, rolls out to... environment that is spun up? Separate App Service Slot?
• Automated UI tests are triggered
• The build is then put in production

How do you guys see this? I'm not sure what the right approach is here.

What is holding me back at this time the most is that the ARM template cannot simply run without errors. It needs to be run once, then you add the secrets to the key vault manually and then run it again successfully. So, if we solve this, things should already be much simpler because we can dynamically create an environment while building/releasing.