As in stop doing changes on the release branch until we release to production. Does anybody do it? What is the need behind it? What do you do when a priority 1 bug comes up in regression? What if the bug is a priority 2?
A company I worked in till very recently did it.
The need is (1) in case anyone inadvertently merges code into the prod branch and a hotfix is required, or (2) it is the holidays so no changes are permitted and the branch is locked down.
If a production bug comes up, it is fixed and signed off in the UAT environment which should be a mirror of the production code. After that it is merged to production and pushed out as a hotfix.
If the bug is a P2, it is just prioritized into a future release cycle.
Pretty much what @gerardmccann said but we still do it for our main (old) legacy system for release / integration testing. We have spent a lot of time improving pushing code to the integration environment earlier so our automated tests can give quicker feedback including visualising them through screens across our development floor.
We have 3 environments at the moment. Qa,
Staging, production. When developers are working on a feature prior to the release being completely ready they merge code to master which auto builds to QA and we do incremental testing. Once the features are code complete we cut release branches to staging for full regressions. This frees up QA to continue forward on master which results in no dev down time. Regressions are performed on stable release branches with no code fixes. Any bugs found during regressions are triaged by the triage team and risks and challenges of fixes are discussed. If a blocker bug is found it is fixed regardless the risk or delay in a release. The dev merges their fix to the release branch and targeted regressions are done.
If a priority hotfix is required during release we will build the fix to QA test the fix then push it to production. Merging the code back down the environments.
These things work for us as we have a relatively short lived release branches and regressions and fixes are done over a 24 hour period of time. That being said working in a startup you sometimes move more quickly than qa would like so we may prioritize several bug fixes as a fast follow on release to stabilize features or polish some rough design edges.
This all results in a release pipeline that should not block development of upcoming features or block hotfixes that need to be released during a regression phase. We are moving to a many to one model of server + branch deployments. Code can be built to any cluster at any state and not block the pipeline for releases. This allows for longer release branches and hotfix’s that can be built to its own environment with only the code currently on production plus the hotfix. That test ops approach allows us to use Kubernetes, helm, and docker to deploy code at will where we want it when we want it, rather than the more intense pre-planning releases currently require
So there is no release branch on your case? Sounds like a set up that multiple teams co-exist in the same code but don’t work towards the same release.
I’ve heard about folks code freezing during the holidays. We just don’t release software, end result Is the same I guess.
@phillipe this sounds very similar with what we have. Occasionally devs get a bit “branch happy” and prepare the release branch very early, and then we see that all features are not in so we merge up and out again, but that is another story I guess
Don’t see what a code freeze can help with
In the company’s case, there were so many branches and so much activity it would make your hair curl . Having a code freeze was to prevent inadvertent changes in a very simple yet robust way. By way of an example of why this was necessary: code merges were done by a build team who were not involved in code creation. The communications pipelines with the team were not great. There were a lot of environmental changes needed between the environments and these were done manually in config files by the team, which we had to test in prod as a sanity test before depoyment via a special URL. In addition to this, there could be past merges into production for hotfixes that were not in the about-to-be-released code, i.e. it had not been down-merged into the lower env branches. Truly like trying to piece together a spider web!
One of the company’s key priorities was to simplify and professionalize the entire process including building in devops aspects, Team City and Octopus. During my time working there they made some inroads, but the priority to ‘run the business’ (perhaps understandably … though not sure on this…) meant resolving the above got prioritized down the list somewhat. I guess the counter argument is that stopping all non-vital reseases and really addressing the release process could have resulted in long-term savings than the short-term cost … but these things are a judgement call.
In termns of holiday code freezes, I too have worked in companies where they just don’t release code. Referring to it as a code freeze is kind of a term, though I think the source branch would have probably been locked down in some way as well just in case.
Git allows you to create tags. So, you can just mark the release versions with tags and continue to work on the development branch.
We have a feature freeze, then a week of testing and bugfixes on the release branch. We use the term “code freeze” very loosely to mean “no further changes should be required, but all serious bugs will be fixed, time permitting.”
I can think of environments where a true code freeze would be necessary in order to ensure that production code is fully tested before release. Anything safety-critical, like medical, aerospace, industrial control or automotive applications, where defects could cause serious real-world harm, and patches are difficult or impossible to apply. I’ve never worked on embedded systems, so I haven’t experienced it myself.
We had discussions for that with the team to tag feautures, epics or even stories. Are you using tags? How did that work out for the team?
I would say that it will be very contextual, depending on the project as a whole.
In my case, we use heavily GitHub’s Draft Release to keep a list of all the tickets that were included since the last version. When this list would “make sense”, we would create the tag itself.
Most of the time, we will use Semantic Versioning to evaluate if the list of changes would make something releasable/taggable.
For us it is semi a thing as in we do not freeze the code, but the overhead of actually getting the product into production is quite high and requires a lot of coordination. So we will typically not fix the bug in your example in that release, but instead in the next. So it is more a point in time where there will be a release train that you cannot change which becomes a soft freeze.