Lets say I have the following branches for my application in TFS2012.
May2013 and June2013.
For deploying these applications I am using TWO different build definitions. One that points to the May20123.sln and one June2013.sln. The builds are doing the exact same thing, only difference pointing to different source code.
I would like to only have one build definition which starts with popup where I can choose which branch to deploy. Is this possible?
(This is just a simple example, the actual scenario is much more complex). I am aware that could change branching strategy...
Thanks!
I do not believe this is possible out of the box, but the Clone build definition feature if TFS 2012 should make your life a lot easier. Simply, create a new branch and then clone an existing build.
Related
I have been working with TeamCity, Jenkins and Bamboo my last 8years. Latest 2years very involved in ContinuousIntegration factory setup and mainteinance on my team with very good results, giving me a lot of habits about how to deal with builds, artifacts and pipelines.
Now, i'm on a new company, new team, new CI, TFS2015, first time for me.
Just one month before I arrive to this new team they were on TFS2012, with XAMLs, so I took the migration to vNext builds.
At first look, I found on vNext builds the classic build definition, i mean adding steps as a single task to the build, instead of monolithic XAML file.
But with the time, i was trying to create more complex builds, like TeamCity build chains, but this is not possible, strike one...
Then, I was trying to deal with multiple branches, one continuous build for each branch (we are on TFSVC), create packages from each branch, and I found I was duplicating my builds just to change repository paths and a few details, so I moved builds to templates trying to reuse build definitions, introducing variables to generates paths(for repos and branches) and versions and expecting to change only in one place the build and having this changes reflected in all builds derived from templates... but that's was not the case... :
variables are not accepted everywhere, like in repo paths.
can't change templates after created them, just replace them, and builds created from templates are not affected after template is changed.
strike two ?.....
I'm wondering if maybe I'm doing things wrong with TFS, maybe this is a different system and I can't do things like in other CIs.
Any advice in how to approach TFS to have a good, dynamic and reusable set of builds ??
here isn’t the feature that the changes of a build definition or template affects other existing build definitions.
If the build steps of build definitions are the same for each branch, you just need a build definition and add filters for each branch (Triggers > Continuous integrations (CI), after that it will uses corresponding source to build for CI build, for example, develop branch changes > Trigger a build automatically with develop branch source.
On the other hand, you can change branch and source version when queue build manually or through REST API.
If the build steps are different for each branch, you need to modify the definitions independently for detail requirements.
Let say there is a team working on main Git repository using branching model. Now a second team joins and is starting to work a subset of a project. As the starting point they need to collaborate on one folder from the repository. They are not allowed to see rest of the code base. What is the best way to achieve that?
Going forward they would need to be able to merge their changes into the main code base and get any updates from that one folder along the way too.
This is all based on Windows OS with Atlassian Stash and Git on internal network.
That would mean that one folder needs to be its own repo:
added as a submodule (tracking a branch) in the main Git repo
forked by the second team, for them to push to the fork and make PR or synchronize from the original folder git repo.
I would suggest separating the subset into a sub-project, and use language-specific ways to deliver it during building of you main project. For example, if you use MS Visual Studio, you could turn it into library or module and use nuget to deliver it during build of your main project.
In my experience it appears to be much more convenient than using submodules, when it comes to merging.
Another reason to do that - and maybe even more important one - that the other team would be able to handle the project as a compilable and testable unit, instead of a pile of source files.
We recently adopted the concept of feature branches in one of our bigger projects, to segregate work on different aspects of the product that can be completed independently of each other.
For each so-called feature, we are creating the following:
a branch from 'main', aptly named after what the feature is supposed to be
a new team in the project portal, containing the people that will work on the feature
a build definition to validate check-ins against the source on the branch
The main point I would like to see discussed here is about the build definition. Currently, each one of them is set to gated checkins.
The question then, is: what is the best practice on associating work items to a build?
In our case, these feature branches are supposed to be disposable: we would like to be able to delete these builds/branches/teams later on when the feature is complete, but still be able to track them throughout the product lifecycle.
If I associate work items with these temporary builds, I'll lose tracking capability later on when the feature implementation ends. At the same time, I just found out that gated checkins always associate work items, regardless of what is configured in the build definition.
Would it be feasible to disable work item integration with the feature branches (in this case also converting them from gated to continuous integration) and enable it in the main build, so that these features can be tracked in the main product line? Or maybe this should be only enabled for Release build definitions, so that we can find out what was integrated on a certain release? For those of you who follow the sprint/feature concept, how do you handle this situation? Do you also have a build for each branch?
Update:
I just found something similar (but not exactly like what I wanted) in this question. The answer there lead me to a plugin that automatically associates work items on merge checkins. This should offer great traceability on it's own, so I think I'll give it a shot.
Would still like to hear what your thoughts are in regards to the builds in this scenario.
You're approaching this wrong IMO. You shouldn't be worrying about associating Builds and WI's, but rather associating Changesets and WI's. When your developers check-in changes in the feature branch you should ensure that they are linking them to the relevant WI(s). You can even enforce this via a Check-In Policy.
Now if you ever want to inspect that feature in the future to see all the changes associated with it, you can by inspecting the Feature WI, and looking at all linked Changesets. Even if you delete the branch all the Changesets are still available.
I have luntbuild set up and working great for my project, with several different builder schedules running on trunk. Now, I just created a branch, and I want to add at least one schedule (and corresponding builder, if necessary) to build that branch (I want the branch built separately from trunk).
Is this possible? Some others in my company have just created separate projects in Luntbuild for their branches, but I feel like that might not be the ideal solution.
So, to reiterate, I want to build this branch continuously. If I just add a second module to the current setup, it tries to build both trunk and the branch together. I want them build separately.
Thanks for any insight!
EDIT: The bounty is about to end, and still no answers. I have worked around the original problem by creating a new project in LB, but I feel like there must be a better way.
Although I've never used Luntbuild before, continuous integration does interest me. I found the following link and hope it is of use to you: http://osdir.com/ml/java.luntbuild.user/2007-10/msg00088.html
Please drop a comment on this if it does work, I am rather curious to see what the final solution is. Good luck!
If I have a C# solution with multiple projects in it, what would be better, to have the Git repo created in the solution folder, or in each individual project folder? Multiple developers will be working on the projects. What are your experiences with this?
I use several (sometimes overlapping) solutions to contain a collection of related independent applications and shared libraries. As others have mentioned, you really don't want to have a single Git repository containing the source for multiple, independent projects as it makes it much too difficult to track isolated changes.
So, if your solution is structured as mine is then you will definitely want individual Git repositories for each project. This has worked well for me for ten to twelve applications and doesn't create as much maintenance overhead as you might think.
If your solution is truly monolithic (and you're sure you want it that way forever and ever), then it probably makes sense to only have a single repository.
It depends. git repositories are most suited to containing a single configuration item with its own independent lifecycle. If your projects have their own release cycle and are shared between multiple solutions then it might make sense to have them in their own repositories. Usually, though, it is the solution that represents a configuration item with all the constituent projects forming part of the same build. In this case a single git repository at the solution level makes more sense.
git submodule is probably worth consideration here. Each project gets its own repo, the solution gets a repo, and the projects are submodules.
I assume that your solution represents some kind of a product while the projects are just a part of the product.
In this situation I would create the repository on the solution level. This way it is a lot easier to build the whole product at once, especially if the projects depend on each other.
Some though and 3 solutions on the subject can be read on that blog:
https://www.atlassian.com/blog/git/git-and-project-dependencies
package management tool, i.e. nuget in VS, so using reference to a package/compiled module
git submodule (only with command line in VS?)
other build and cross-stack dependency tools
Another solution is just to add a project from the other repo and let it out of the current repo, and latter use the Team Explorer to commit its changes.