Stable Release/experimental builds

[amund7]

Currently we have an automated build server (emons.visualstudio.com , now called Azure DevOps), that builds, packs, creates installer ("deploy") and posts to github as a release.

Problem is, this happens with every checkin, merge etc. and they are not necessarily ready for release.

It would be cool if we could post this as nightly/experimental/latest builds, but somehow keep track of properly tested builds that we want new users to download and install?

Does anyone know how to improve on this ? Brian-Man has access to administer these builds, let me know if you want access too Bokonon.

See https://github.com/amund7/CANBUS-Analyzer/releases

[Bokonon79]

I think you've got the right idea that we need to have separate "dev" and "release" branches, because right now, "master" is effectively serving as both.

I don't have any experience with Azure DevOps, but I am assuming that build/deploy automation can be configured on a per-branch basis, and is currently configured for the master branch. If so, a couple of options might be:

Option 1: Make "master" the release branch. Create a new "develop" or "Latest" branch for the project, and merge all PRs and other changes into this branch. When this branch is confirmed stable and ready for release, merge to "master", triggering the build/deploy automation.

Option 2: Make a new "release" branch, enable build/deploy automation on this branch, and disable that automation on "master". Continue to use "master" as the main "development" branch, merging all PRs and changes there. When "master" is confirmed stable and ready for release, merge to "release", triggering the build/deploy automation.

[amund7]

I like option 2. Then we can also probably get an overview over which commits has happened since last time, and can make a changelog.

I'll try to make the build automation only build a branch we call 'release'.

[amund7]

On second thought, I really like that we have super fast, always latest builds. In the event we break something, we can always delete that release manually. I think I'd like to keep it this way for a while and see how it goes.

[scottstout]

You can set it to only trigger the release on certain branches and/or commits with certain tags. Or you can do test relase that goes one place (e. G . More private)and only when ready you trigger the production release when you are ready (by setting approvers). Scott

On Sun, Jan 6, 2019 at 4:40 PM amund7 ***@***.***> wrote: On second thought, I really like that we have super fast, always latest builds. In the event we break something, we can always delete that release manually. I think I'd like to keep it this way for a while and see how it goes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAICblmTQ3NVnnvBl8Gou3W1XPDnMtPrks5vAntugaJpZM4ZyEx-> .

-- Scott Stout mobile (713) 320-4376

[brian-man]

Recommendation:

1. Create a release branch
2. Adjust configuration so that master and release branches both automatically generate and publish builds with each commit
3. General public uses release branch builds and early adopters can use master branch builds with the expectation that stability isn't the priority for master branch builds

[amund7]

Agreed, but the problem is, how to distinguish those builds here on Github? Tags maybe?

As it sits today, the microsoft server builds, creates installer, packages, zips AND uploads the files to github, all automatically.

Or, would it be better to deploy to microsoft 'blob', if that has become free now?
If this could be combined with auto updates (that requires a steady URL from which the installer can be found), that would be a big improvement, which solves #23