Closed shaedrich closed 1 year ago
Would this quick release still be tagged and merged into master and develop or would it be more like a snapshot/nightly release?
I intended it to be tagged and merged like usual as it was meant to be just a shortcut for start
and finish
. What would be the benefit of the snapshot/nightly release implementation?
What would be the benefit of the snapshot/nightly release implementation?
My personal thoughts on it are better integration with the ideas behind CI/CD. I personally have no real world experience with CI/CD though I do have a 30,000 foot understanding of the benefits. So please forgive me if I happen to explain something incorrectly. I have read that git-flow is a barrier to CI/CD citing a number of different reasons.
The main ones I have seen are: 1) The use of feature branches. Since any new feature being developed is not merged into the code base before completion you are failing to do CI properly. 2) Since a "release branch" is only created when a release is actually being made your not doing CD properly. Usually the fact that changes may still be committed to develop during the release process and not included are stated as part of the reasoning for this. 3) Similar to point 2. Changes made to develop are only released when a "release branch" is created
I think the PR Quick option to create release from existing feature branch original could help to address this point 1.
I feel with the use of snapshot releases this could help to address points 2 and 3, if a snapshot release were to be made anytime a change was made to develop. The same could be done for a nightly release. The only difference being that with a nightly release it is done once a day at a set time and would include all the days changes to develop in a single package.
As a side benefit IMO since snapshot/nightly releases are usually what the next released version will be. "Depending on how far away the next release is of course" it would provide for more options when wanting to use "the latest" version.
At the company where I work, we use CI/CD and continuously try to improve upon it. Strict implementations of CI/CD might have problems with it, however, frankly, I've not heard of it thus far. That might stem from its wide variety of implementations. I don't really see git flow as a tool to that extent CI/CD is. It's just a helpful wrapper to git and CI/CD should be able to adapt to it and still have its benefits. But that depends on the company's/project's development strategy.
On things, I stumbled across was a connection between gitflow releases and GitLab's Review Apps. One improvement would be, instead of never pushing the release branch and deleting it upon finishing the release only minutes after creating it, to have a CI/CD step to create a Release Candidate. That is somewhat similar to your snapshot suggestion.
To achieve the right version number, especially, when it is proposed and/or validated, is to not just have gitflow.prefix.versiontag
git config but more like a template.
Another strategy, similar to your nightly build suggestion, is a deployment methodology called Blue Green Rollout by GitLab. That in return is closely related to Feature Flags.
release create is now implemented in the 2.x release I still need to update documentation. I know classic developer not wanting to write docs lol. That being said,in total 6 new hook scripts have been added and 1 missing script. The missing script was filter-flow-release-finish-version this script allows for modification / creation of the version
The new hook scripts are in order of execution filter-flow-create-start-version same purpose as filter-flow-release-start-version pre-flow-release-create runs before creating the release branch same as pre-flow-release-start post-flow-release-create runs after creating the release branch same as post-flow-release-start filter-flow-create-finish-version I'm not sure how useful this one will be if using create-start-version or via versa pre-flow-create-finish runs right before attempting the merge commit same as pre-flow-release-finish post-flow-create-finish runs after the merge commit same as post-flow-release-finish
Sounds good 👍🏻 Yeah, sometimes I like writing docs, but I can't find time for it. I like the docs to be by the book but then again I think docs are kinda redundant since what I'm writing in plain text, I've already written in code 😓
then again I think docs are kinda redundant since what I'm writing in plain text, I've already written in code 😓
So true, I think a lot of it for me is I was part of the team that re-wrote the majority of the internal KB for Verizon Wireless and when it was all said and done none of us were mentioned as the author let alone a contributor to the docs.
Oh, this is … somewhat less than perfect
Oh, this is … somewhat less than perfect
Refereeing to my comment or a bug in release create?
I was referring to you not being mentioned as the author/contributor to the docs
It's always good to check twice but sometimes this can be done without calling
git flow release finish
right after callinggit flow release start
so it would be cool to have something likegit flow release create
.