-1

I use GitFlow as a workflow for versionning for less than 1 month. I've just finished to develop a feature branch which has been merged to develop/. Now, I'm starting a release branch from develop. The release branch will be tested. If tests show bugs, fix will be implemented in the release branch. At the end of that test process I will merge release to develop/ and master and I will tag it.

The person in charge of tests don't know about gitflow. Before, when I wanted to give him a code to test, I would tag the code, create a "release" on Gitlab with zipped source and attached executables (The tester only uses executables).

Now, the problem is that with Gitflow I will tag after tests. This is why I have no clean solution to share executable to the tester. Is there any clean solution to do so?

1 Answer 1

2

There's no need to wait until the end of the testing process to tag the release. Instead, tag each build in the release branch. You can use tag of the format {version}-{build} where build is an incrementing number for the release or {version}-{timestamp} is the timestamp of the version.

If you're using Semantic Versioning, that specification provides specific information on pre-release versions being denoted by "appending a hyphen and a series of dot separated identifiers immediately following the patch version" and adding build metadata by "appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version".

During testing, you may encounter issues. You would merge these changes into the release branch. Depending on the issues, you may decide to bundle several of them into a single new release candidate. That means that you may have merges into the release branch that aren't tagged. Whenever you are ready to put a new release candidate into testing, you can apply a new tag and do the build.

After testing is complete, you can either tag with just the version or you can keep track of which build was approved for release, merge it into your main branch, and move on. You can tag in either the release branch before the merge to main or the main branch after the merge.

2
  • Following GitFlow, "every commit on master is a new release by definition". If your build is based on a commit that is not on main (or master), you are contradicting this "rule". At the same time, if you tag the merge commit on main and you build your image based on that commit, it means that you did not test that same build/commit in the QA environment (because that commit didn't exist yet while you were building and testing your release branch). How do you deal with this apparent contradiction? Am I missing something? Dec 17, 2023 at 10:51
  • 1
    @KurtBourbaki I'm guessing that this is from your other question. I posted a complete answer there, so comment there if something is unclear and I can revise or explain.
    – Thomas Owens
    Dec 17, 2023 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.