My team are finally moving from SourceSafe to TFS 2010, and we are trying to work out our strategy.
We need to be able to put bug fixes into the next service release whilst still working on the current service release. Basically, at some point we will stop bug fixing going in the current release (except a few critical ones) and pilot that release for a week or two. During this time we still want to be fixing bugs so we put them into the next service release. This is separate from the development that will be going into the next major release.
We like the look of the mature branching strategy that involves having a service release branch off of main, a hot fix branch off of service release, and a release branch off of hot fix. What we would then do is have the release branch as the one that we are piloting and still be able to add bug fixes to the service release branch. Then when we finish with the pilot and have made the last critical changes we merge the release branch back into main, via the hot fix and service release branches, and then create a new hot fix and release branch from the service release branch, which will be our next service release.
The big problem I have with this is that I want anything that goes into main to be fully tested. The release branch will be but as we merge it back into main it will pick up any changes that we have checked into the hot fix and service release branches. These changes will not have been tested at this point.
To get around this we are planning on making the devs shelve their changes in the service release branch until after the release has been merged into main. This doesn't seem like the best idea to me, but I can't think of anything else to do to handle this.
Has anyone else had to do something similar and have a better way of handling this?
Related
Git-flow explains the following process for release branches -
Release branch should be forked from develop branch
Release branch should merged back into master branch, and a tag created from master branch.
My question is why is why should release branches be forked from develop and not master? Is there any benefit from doing so?
I can instead
Merge my develop into master
Fork a release from master and then tag the master...
How will that affect the version management?
You almost answered your question in one of your comments:
the purpose of master is to be a replica of a production ready stable code
Let me elaborate on that:
(1) That statement is correct. master is production-ready. According to git-flow every commit (being a merge from a release or hotfix branch) leads to a new release.
(2) If you merge develop directly onto master you might end up with instabilities. That's what we create a release branch for. We use the latest version of develop but test them, make some bug fixes, adjust configurations etc.
Only when everything is fine we actually merge onto master and therefore deploy to our users.
A final - but very important - note here:
git-flow is just one of many ways to organise your code. It's not a this is the one and only solution for everyone and everything. It's just a suggestions, a framework. Adjust it to your needs or use a completely different framework / idea if it does not work for you. I rarely used git-flow in the past 15 years exactly the way it's documented. We always made some adjustments.
One of them btw being very closely related to your question: We would deploy from release and only if that deployment works and reached our clients (Apple's review process, I tell you!) we would merge to master and tag that release.
This may sound strange, but I am having issues with Xcode mixing branches, or at least messing everything up.
I created a new branch (v1.4), then created a new data model and renamed an entity. Had to switch back to previous branch (v1.3) to check something and I get errors at run time on v1.3, it's looking for the new entity name from Branch v1.4 - what the %$^#% is happening. I searched the files, the new entity name is nowhere in v1.3.
I switch branches again to v1.2 and it ran fine. So, switched to V1.3 again - nogo. Switched back to v1.2 and it has the same issue now, runtime error because it can't find the new entity name.
What is happening? Anyone else have this issue?
Any thoughts/suggestions would be greatly appreciated.
OS X 10.11.6
Xcode 7.1.1
==[EDIT]===
I am not real familiar with GIT, just starting to learn. I ran the couple commands as mentioned, get nothing for either git diff commands.
Running git status --ignored I do get multiple files as untracked - still working on understanding why (Separate issue) - couple object files and 2 data models (Was 3, but manually added one to commit.
Also I get 3 ignored files:
.DS_Store
projectName.xcodeproj/project.xcworkspace/xcuserdata/
projectName/.DS_Store
That's as far as I've gotten. Not familiar enough with git to know if these ignored files are the ones I should delete.
Second option - will restoring from time machine fix this? It may be a little extra work for me to recreate v1.4 but probably less time than I've already spent trying to figure out how to fix it.
I do appreciate both comments so far - thank you.
==[SECOND EDIT]==
Thanks again for your comments.
However, do to time and schedule I perform a Time Machine backup before ElpieKay posted the last comment, so I will not be able to test it.
Reverting back did "fix" it as you'd expect, but I did lose several hours of work but life happens. I will keep this for if/when this happens again and try the git clean -df to see it fixes it.
On a side note - while I was switching back and forth between V1.3 and V1.4 trying to figure this out, 2 of the model versions disappeared on v1.4 - i.e. the name turned red in Xcode and when I viewed the contents of the file they were missing. I do not know if this is related or not, but I thought I would mention it. This happened one other time and I thought maybe I did something - I did a time machine restore to fix it last time. Wonder if git clean -df would have fixed it.
When running a deployment in bamboo, it gives the option between 'promoting' a release or creating an old one. Is this just jargon for 'reuse' or is something else happening?
I've not found anything in the Atlassian docs, and only this came up:
You should create a new release if there were changes in your code since the last version. If you need to promote code from one environment to another, using the "Promote" feature is definitely the way to go.
I think that makes sense if you replace 'promote' with 'reuse' makes sense.
If you want to reuse some old releases, then you tell Bamboo promote(reuse) the previously built releases. In this sense, with promote Bamboo means reuse.
From Build Result you can always create new release to deploy, but always the latest build result.
Like it says:
It would seem intuitive to just change it there and try again, but it's not actually editable.
To get to this point, I file-copied the original project, opened it in Bazaar Explorer, saw that it found the history okay, and proceeded to check out the project in its new home. After a minor bug fix, I tried to commit, and it did this.
This isn't a satisfactory answer for my original question, so I'll leave it open for one that is, but I've decided to abandon the migrated repository and make a new one with (partially) migrated contents instead.
I know it'll reset my version history, but I have enough other changes, having been distracted by other, higher-priority projects for a while and coming back fresh, that I think it makes sense to call it a new project that's only based on the old one.
I love the maven-versions-plugin but sometimes I forget to run it for a while. Is there a way to make a maven build fail (and thus have a continuous build fail) when certain important dependencies are out of date?
I think you're approaching this incorrectly. Mail yourself the output of the maven-versions-plugin if you want, but don't fail the build due to changes outside of your control.
Even more, why would you want to needlessly update to the latest versions? I have seen many tricky problems appear due to upgrades which have brought slight changes to previous behaviour.
This, in general, is a bad practice - to update versions automatically. There is no practical reason of using the latest version of any package. If the library you're using satisfies your requirements you should stay with this version for security/stability reasons. And forever.
I think that maven-versions-plugin is an anti-pattern itself.
ps. When and if you want to do integration testing of modules developed by different teams/programmers, it is "integration testing". Even in this case I still think that on-fly version updating is the wrong approach. Root project should not do this integration testing, instead, every sub-module (or JAR, in your case), has to be responsible for integration testing of itself together with the rest of the system. When a sub-module increases its version it has to validate whether everything is still fine, and only then has to release a new version to the repository. And when the sub-module is doing the validation it has to be dependent on statically specified version numbers.