Hello to all guru's out there. I came across a requirement that our TFS needs to support multiple releases. Listed are some of the requirement.
Scenario: We have 2 releases, Release 1.0 and Release 2.0
Release 1.0 needs a patch and will be released as Patch 1.1
The changes in Patch 1.1 can be optionally added to Release 2.0
If there is a new patch, lets say Patch 1.2. It should only contain the changes of Patch 1.1 and what ever additional changes for 1.2.
In relation with item no. 3. The reason for this is some customer doesn't want to pay for the upgrade and just want a minor fix for their current version.
I have come up with a solution but Im just wondering if there are other way or is this not recommended at all because it really is hard to maintain.
Thanks
According to your description, base on my understand as follow example:
version A in Release 1.0,
version B in Release 2.0 ( = version A + new features)
You want an easy way to deploy a "Patch" for version A (i.e. a quick fix of version A without the new features of version B)
In TFS Release Management, you have the ability to deploy
sequentially, in parallel, or in any other user specified order ( you
can deploy manually )
You can trigger a new release with patched version A ( adding some
description regarding patching to identify it later ) with no
deployment conditions and then can manually deploy to whichever
environment you want.
Another way is rolling-back your code to the last known release point, code your patch, shelve the code, then build and release the shelveset.
For more multiple release structure in TFS please take a look to this link: Team Foundation: Multiple release structure which may be helpful to you.
Related
Environment:
TFS 2018 with source code in TFS Git
developers are using gitflow-like workflow (main, develop and short-lived feature branches)
there is a build definition used for CI (off of develop branch)
... and another one for releases (off of main branch)
as project evolves build definitions get updated (new steps, etc)
What is the best approach that allows reproduction of previous builds (or, at minimum, release builds)? (in case if previously made build was lost in boating accident)
Ideally I need to be able to plug in version (e.g. 8.5.12345.1) somewhere, press OK and eventually receive data identical to that produced by corresponding build in the past.
Your best approach is to switch to YAML builds and releases. That way your pipeline is versioned together with the code.
If you don't do that, you may need to clone your build and releases every time you make breaking changes.
Alternatively, use the version diff view in your pipeline to go back to an older version or use the json to create a new definition using the API.
Upgrading to Azure DevOps Servers 2020 will give you more advanced YAML features not yet available in Team Foundation Server 2018.
Note: for truly reproducible builds, you'll need to also find a way to lock the build tasks themselves, TFS and Azure DevOps will automatically roll forward to the latest minor version of a given build task. While task authors should try to prevent any breaking changes in those minor upgrades there are no guarantees. You can also never rely on any tool installers that use a v2.x notation or a task that relies on latest. Azure DevOps isn't ideally suited for full reproducible builds.
You can pin task versions in YAML now, if I remember correctly, this was added in Azure DevOps 2020.
You can set which minor version gets used by specifying the full version number of a task after the # sign (example: GoTool#0.3.1). You can only use task versions that exist for your organization.
See: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml#task-versions
The Tasks docs offer special scripts to pin the versions of out-of-the-box tasks as well.
I am designing a branching & merging strategy for my project (We use TFS). Project has plans to have multiple released versions. Currently we are testing v1.0alpha and working in v2.0
The plan is:
After imminent green light from testers, version v1.0 will be released to one client.
Version v1.1 (already in dev) will be deployed to 5-6 clients
Version v1.2 would be installed to dozens of clients.
etc.
We will try to force upgrade of old clients to most recent versions but due to the nature of project and market it can be months (years?) for clients to upgrade.
We want to use standard gitflow but seems more appropriate for having a single version. I have designed a simplification of gitflow:
The approach is:
If a client wants a bug fixed, we will fix it in the Release branch of his version and he has to upgrade to the latest revision of his version. For example client in v1.0 that has a bug would have to upgrade to v1.0.5. If the bug happens in other versions we will fix it there.
If the client wants a new feature we will develop it in the latest version and force them to upgrade if they want it. For example client in v1.0.5 that wants new version will have to upgrade to v1.2
If all the clients of a given version upgrade we will delete that Release branch. For example when the client of v1.0 upgrades we will burminate v1.0 Release branch.
So my questions in order of importance are:
Will my approach work? Any problems that you can see?
Does git-flow have any pattern for this "multiple versions scenario"?
Gitflow has a Master branch. Is it ok not having a Master branch? Could we consider the different Release branches as "Master"?
How will you name Dev and Releases branches?
Your approach should work. There is nothing magical to GitFlow, and variations catering to your needs are fine. Git itself has no issues with a different workflow. A good example is Github flow, take a look at http://scottchacon.com/2011/08/31/github-flow.html .
A few things you could consider:
a) "Principle of least surprise": Try to keep as close to a standard as you can. That means you i) point devs to available documentation on the web instead of writing up everything ii) make it easier for new devs to enter or just work with your projects.
Thus, you should keep the master branch, not because it is needed - it is not, but because it might confuse people when it is not there, and you would have to explain that for years to come.
Branches in git is "just" names (well, a bit more, but you get my meaning), so the only reason to name them the same is convention - making it easy for people.
b) How many devs are working on the projects? If there are many, you could consider the Dev branch an integration branch, and use the master branch as the stable branch. Having a dev branch that you allow to be unstable might solve many issues with many devs. Two teams committing, one from feature and one from a hotfix, the build goes red, the teams blaming each other, the third team try to get out a new release branch, but can't. Having a stable, always green build master branch, which you even could protect with pull requests, is very nice, and makes for a more relaxed environment.
2) Basic Gitflow is centered around a release, so not quite. You have multiple releases at the same time. So you are nearly there, but standard tools, like [Jakob Ehn's] (https://github.com/jakobehn) Gitflow extention to Visual Studio - which is supergreat - will make you try to close a release before you are allowed to open a new one. Ask Jakob to relax that, and the tool will work for you. Otherwise, just follow the convention, but do it manually - that works too.
3) See point 1 above about master and why it might not be a good idea to not have it. But of course you can consider the release branches as kind of masters, but they don't really behave that way in your description. And if so, which one is the real master, the one you create feature branches from, and the one you regard as the latest? Having a stable master solves a lot of questions that pops up without.
4) Dev or Develop, then features should have a name of the feature as close to what it does as possible, like Dev/NewHelpPage, or Feature/NewHelpPage (to be closer to gitflow convention). Release branches, it looks like you already follow the semantic versioning (http://semver.org) principle, so why not use that: Release/V1.0, Release/V1.1 and so on. A hotfix branch is then Release/V1.0.1 .
Let the naming be so that devs easily understand what it is, preferably without needing to have to ask anyone around.
Keep it simple, follow conventions as far as you can, and it tends to work out. Git itself works for mostly any branching scheme.
[Edit]
Just had a quick chat with Jakob, and he said he had requests to support support-branches, which is probably what you are really after. He also pointed to this excellent post on different gitflow scenarios, at the bottom there is the flow for support-branches.
I mean is it ok to have v1.0 as main branch and v2.0 as subbranch? And what if I'll create v3.0 SDK, subbranch of a branch v2.0?
OR
create new repo with "v2.0"/"v3.0" postfixes?
So the question is: what is the best way to support multiple different versions of your SDK and in the same time keep them in one place ?
Thx.
I would definitely create different repos per version. Assuming that those versions are different enough to be called 1.0, 2.0, 3.0. That will make life really easy for you in order to manage pull requests. Also better when it comes to branch generation.
IMHO, if you keep only one branch alive and overwrite versions, could be a mess in the end. Imagine that you have a new feature under development (v1.0) pending from an specific commit, whilst v2.0 has been improved and it os ready to be delivered. Sum up a pull request from a developer that has fixed loads of bugs in an early release of v1.0....
In this case, again IMHO, divide and conquer. Repo per version. Branches per status (feature branches, stable branches, release branches), and pull requests to handle external changes.
Hope you like it!
I've currently got a number of Team Projects all happily managed by TFS.
I have one project, a windows app, that is currently in use and before I ported the code base to TFS, we manually used to maintain both the production build and a new development build using scripts to copy/merge the files.
e.g. App1 v1.x - production and
App1 v2.0 in development.
Before TFS we manually "merged" to bug fixes from the development build into the production build - so where applicable bug fixes from v1.x were also fixed in v2.
In this particular case v2 is quite different, re-factored ui, etc. The question I have is what is the best way of porting this scenario to TFS.
As I see it I have two options:
Create a new Team Project and continue manually "merging" applicable
code files.
Create a brand from the current project v1 and replace / overwrite the project piece by piece in VS so that the source control can manage the changes back to the Main team project.
V2 has a few additional class libs too - if that makes a difference.
Typically, this is the strategy we use to do branching and merging:
The project starts. All team members are working on version 1.0 in the single CURRENT branch.
Project approaches a milestone or release. Make a branch that will be used to stabilized the code for production in PROD 1.0 branch. Now half of the team stabilizes the product on the branch and half of the team continues doing new (riskful) stuff on the CURRENT branch.
PROD 1.0 branch is ready and delivered in production. The branch stays intact to provide maintenance and support on the delivered version. Fixes are made on the PROD 1.0 branch and merged into the CURRENT branch.
Project approaches another milestone or release. Make a new branch that will be used to stabilized the code for production in PROD 2.0 branch. The same mechanism is used as described before.
Using this branch-per-release strategy, you always have a branch per shipped and to be maintained version in which fixes can easily be propagated forward and backward between versions and the mainstream CURRENT development line.
With this respect, we use a TFS team project for multiple releases of a certain product. This limits the overhead creating and maintaining the project spaces.
In short...To branch!
It seems your code between versions is that much similar that you should be fine by simply branching your new release.
In general, changing to a new Team Project makes sense if you have one or more of the following:
a totally new bread of requirements and/or different Work Item types
completely different technology, in other words you have radically changed the design & merging is more loss than gain
need to store docs & other tokens in another SharePoint site
different development methodology - process template
different teams of people working on both sides, possibly want to restrict users from viewing v1 or v2
plan to release both products in completely different release cycles
need for totally separated reports
Reading your post I don't recognize the need to go after creating a new Team Project - of course I might be wrong.
In case you decide to go with the branch variant you could be greatly benefited from the impressive Visual Studio TFS Branching Guide 2010, on how to shape the structure of your codebase.
How do you version in JIRA when your versions are like 4.8.{TFSBuild}.{TeamCity.Build}?
Do I simply create a 4.8 Version in Jira?
However what would I set the release date to?
The problem is that our versions are dynamically and created based on the build# from tfs and the Team City build#.
What is now the best way for me to create versions in Jira?
Only the Major. Minor is hardcoded for now and for every few bug fixes we upload the release to the live server.
Jira versions are primarily a planning tool (especially if you use Greenhopper aka Agile, where you can have a version hierarchy).
So that's different from a build. It may take a thousand builds to achieve the functionality planned for a "FixFor" version.
On the other hand, "Affects" versions are used to track in which build a particular bug was found. So it'll pay to rename the "current version" (when you mark it as Released) to the actual build, as Hugo suggests. And cleanup/close/move any outstanding issues at the same time.
I would suggest to name the upcoming version that doesn't have a fixed name yet something like "Next release".
When you actually do release that version then you can change the version name in Jira to reflect the correct name.
Using Jira For Project Management - Creating Versions
We use Jira for project management of daily task assignment and we like to have versions either by week or by month. This lets us assign work for a week and is very helpful with the Greenhopper plug in. Basically, you:
Open the project from "Projects"
On left side, click on "Versions"
We have version 4.4 so might be slightly different other Jira versions.