I am involved in some TFS setup at my new job and one of my tasks is to setup the location of the common framework assemblies in TFS so that the other projects can reference them. The only way I can think of is to branch the assemblies from the framework folder into all of the other projects. The issue with this is that anytime I want to update all of the projects with the new assemblies I need to merge each branch one at a time. Is there not a way to merge all at once?
I mentioned that we should use NuGet but that would rely on the developer doing a get on the new version, they want to push it to the project to ensure that it is being used...
Any advice would be much appreciated!
NuGet is the right way to do it. Make your Framework build publish your NuGet package to a local NuGet Server from where is it is referenced by everyone. This way, when you upgrade framework, everyone will get it and you don't have to push it.
After doing lots of looking around I believe the answer to the problem is here in these two articles:
http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx
http://geekswithblogs.net/jakob/archive/2010/12/08/dependency-replication-with-tfs-2010-build.aspx
I'll need to adapt some of the ideas within to TFS 2012.
Related
We are starting to use TFS2013 (we use svn still, but for a number of reasons we're putting new code on TFS).
I have a solution that contains a project with an EF database model and I would like to share it with a different solution (to be more specific: there is a client website solution and a separate one for backend).
On SVN I would have created svn externals - I would be able to share the code easily and if I branched, the shared project would have a nice copy on branch as well. Moreover, both projects would have the most up-to-date version of the db model, which suits me perfectly.
TFS 2013 seems to push be pushing towards NuGets. That means, that if I create a nuget package of the db project:
I will have to update the db projec separately each time there is a db change, release it and then update all projects that use it
If I branch, I'll probably have to create a different nuget package for the branched version and amend the nuget reference on merge
It pollutes the nuget repo with things that are not exactly worth a repository (in case of a DB model, you want to have the latest possible version because a website will probably break if you don't, no point for versioning so that the build doesn't break)
I spent some time trying to find a suitable solution, but the best idea I found is just referencing the project from a different solution - the problem with it is, I would have to make the root folder for the build be higher than just the solution and that would add several more projects that I don't need. Another idea is referencing by branching, which was good for TFS 2010 with multiple projects, but I can't fit it into my scenario (we have a single 'Main' node where we put all solutions).
So, how would you share a DB project on TFS 2013?
We have currently released our code to Production, and as a result have cut and branched to ensure we can support our current release, whilst still supporting hot-fixes without breaking the current release from any on-going development.
Here is our current structure:
Project-
/Development
/RC1
Until recently using Octopus we have had the following process:
Dev->Staging/Dev Test->UAT
Which works fine as we didn't have an actual release.
My question is how can Octopus support our new way of working?
Do we create a new/clone project in Octopus named RC1 and have CI from our RC1 branch into that? Then add/remove as appropriate as this RC's are no longer required?
Or is there another method that we've clearly missed out on?
It seems that most organisations that are striving for continuous something end up with a CI server and continuous deployment up to some manual sign off environment and then require continuous delivery to production. This generally leads to a branching strategy in order to isolate the release candidate to allow hot fixing.
I think a question like this raises more points for discussion, before trying to provide a one size fits all answer IMHO.
The kind of things that spring to mind are:
Do you have "source code" dependencies or binary ones for any shared components.
What level of integration / automated regression testing do you have.
Is your deployment orchestrated by TFS, or driven by a user in Octopus.
Is there a database as part of the application that needs consideration.
How is your application version numbering controlled.
What is your release cycle.
In the past where I've encountered this scenario, I would look towards a code promotion branching strategy which provides you with one branch to maintain in production - This has worked well where continuous deployment to production is not an option. You can find more branching strategies discussed on the ALM Rangers page on CodePlex
Developers / Testers can continually push code / features / bug fixes through staging / uat. At the point of release the Dev branch is merged to Release branch, which causes a release build and creates a nuget package. This should still be released to Octopus in exactly the same way, only it's a brand new release and not a promotion of a previous release. This would need to ensure that there is no clash on version numbering and so a strategy might be to have a difference in the major number - This would depend on your current setup. This does however, take an opinionated view that the deployment is orchestrated by the build server rather than Octopus Deploy. Primarily TeamCity / TFS calls out to the Ocotpus API, rather than a user choosing the build number in Octopus (we have been known to make mistakes)
ocoto.exe create-release --version GENERATED_BY_BUILD_SERVER
To me, the biggest question I ask clients is "What's the constraint that means you can't continuously deploy to production". Address that constraint (see theory of constraints) and you remove the need to work round an issue that needn't be there in the first place (not always that straight forward I know)
I would strongly advise that you don't clone projects in Octopus for different environments as it's counter intuitive. At the end of the day you're just telling Octopus to go and get this nuget package version for this app, and deploy it to this environment please. If you want to get the package from a different NuGet feed for release, then you could always make use of the custom binding on the NuGet field in Octopus and drive that by a scoped variable depending on the environment you're deploying to.
Step 1 - Setup two feeds
Step 2 - Scope some variables for those feeds
Step 3 - Consume the feed using a custom expression
I hope this helps
This is unfortunately something Octopus doesn't directly have - true support for branching (yet). It's on their roadmap for 3.1 under better branching support. They have been talking about this problem for some time now.
One idea that you mentioned would be to clone your project for each branch. You can do this under the "Settings" tab (on the right-hand side) in your project that you want to clone. This will allow you to duplicate your project and simply rename it to one of your branches - so one PreRelease or Release Candidate project and other is your mainline Dev (I would keep the same name of the project). I'm assuming you have everything in the same project group.
Alternatively you could just change your NuSpec files in your projects in different branches so that you could clearly see what's being deployed at the overview project page or on the dashboard. So for your RC branch, you could just add the suffix -release within the NuSpec in your RC branch which is legal (rules on Semantic Versioning talk about prereleases at rule #9). This way, you can use the same project but have different packages to deploy. If your targeted servers are the same, then this may be the "lighter" or simpler approach compared to cloning.
I blogged about how we do this here:
http://www.alexjamesbrown.com/blog/development/working-branch-deployments-tfs-octopus/
It's a bit of a hack, but in summary:
Create branch in TFS Create branch specific build definition
Create branch specific drop location for Octopack
Create branch specific Octopus Deployment Project (by cloning your ‘main’ deployment
Edit the newly cloned deployment, re-point the nuget feed location to your
branch specific output location, created in step 3
I have been working with a TFS project that supports copying build output to source control. If I open the build definition, this is under "Build Defaults". There is an option to copy build output to a source control folder.
I have just installed TFS Server 2013 (with update 2) and I want to use this feature with a new Team Project. However, if I create new build in VS 2012 or VS 2013 on the new server, I am not given the option to copy build output to source control. What gives?
I am not looking for a workaround, I want to know what to change so that my server acts like the first one I described. Thanks!
Screenshots of what I'm talking about: http://imgur.com/a/mhDNQ
This was a feature that was temporarily present in TFS, but I believe has since been removed. If I recall it was put in there specifically to support the cloud-hosted elastic build servers which didn't have access to network shares to drop the builds in.
Most people recommend against putting your build outputs into TFS. The best approach is to publish them to a NuGet feed.
In any case if you want to put your build outputs into TFS (or a NuGet feed) you'll have to modify the build workflow to do that yourself.
Open a new build definition > process.
Under template select new and you should be able to choose project and folder. Find your original template and link it. Your option should appear.
In TFS 2013 this has changed to be "store drops in TFS". When you select this option the drop I'd stored in a new inversioned store that you can access.
While you can easily get the files out as indecision or zips the built in tools like release management do not support it yet. I would recommend that you use this option but publish your assets to a nugget repository.
If your TFS is available online (VSO or https) then you can use MyGet to dynamically load the nugget packages that you are publish and make them available on a feed.
http://docs.myget.org/docs/how-to/use-tfs-online-git-with-myget-build-services
I'm using Visual Studio Online for my TFS needs, and I have a pretty big solution which contains several web projects.
How can I set up automatic deployment of a specific project in the solution to a specific website on Azure?
The default workflow used to deploy in VSO does not seem to handle this scenario.
The "first" web project found within the solution is chosen for deployment according to this discussion. Note that the discussion relates to git on VSO but it seems to hold true for builds using the VSO CI workflow.
According to the discussion changing the project names to influence the ordering should/might work but results seem mixed.
We chose to add a second solution only containing the web-project to deploy, its dependencies and tests. This will not work if there are dependencies on other web-projects.
Also take not of this article on a configuration-based approach, a question that this one might be a duplicate of or a question concerning actual deployment of multiple projects into one site.
I have a solution that currently builds nicely in TFS. I have just added a Sandcastle help File Builder project to it so that the help files can be generated. Now the solutions takes ages to build locally (it has also doubled the build time on the TFS Server).
In practice I'd be happy generating the help files once per day, or only when specifically requested as part of a build.
I tried creating a separate solution (for a new build) which included the Sandcastle project but I got a warning saying that the projects were already under source control.
What is the best way to configure TFS/the solution for this sort of situation? Can I have two builds that run on separate schedules and include/exclude certain projects in the solution?
You can create a new solution configuration that excludes building your help project. Then in your TFS build you can specify which configuration to build. You could have a CI build that doesn't include your help project, and then a nightly build that includes everything.