I have a "SOA" styled application, with a single solution containing almost 100 individual projects (which are a solution within them, i.e. they can be run independently). I have created a build and release definition in TFS 2018 and everything works perfectly.
The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time.
I don't want it. I need it to be specific to the service in which changes are made. Is there any way to do it?
Creating multiple build/release definition which is tied to the specific path of each service should solve it but I don't want to go down that road, because I will end up creating 100's of definitions.
Is there any other way to do it?
This is for a .Net application, hosted in TFS 2018 (On-premise).
The solution structure is as below:
AllWCFService.sln
|_Service1.csproj
|_Service2.csproj
|..
|..
|_Service100.csproj
Each Service can also be run and hosted independently.
This is my first question here. I apologize for any confusion.
As you have mentioned, by using Path filters on the Build definition should be the easiest solution.
With the proper path to the project in the Path filter only the proper Builds spin up, and any projects untouched do not trigger a build. Each build has it's own release which then deploys the specified app to it's own destination. As a ugly workaround, you could set up a group each with 5 services which will reduce 100's of definitions to 20's.
Otherwise, you have to customize your build definition/pipeline. Use some scripts to determine or judge which part of your Servicex.csproj changed base on your name.
Then call msbuild with /t option to build a single or multiple projects.
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
specify project file of a solution using msbuild
It will only build specified changed project and generated corresponding artifacts. Then add scripts in release to specify path according build generated artifacts to deploy each service.
Hope this helps.
Related
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
Currently we have many projects in TFS, one of which is a core project that many other projects reference. If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order). It would be nice to be able to set the core project as the highest priority so that its build always runs first when changes to multiple projects are checked in. Is this possible?
There is no way to set the default build priority for a Build Definition. Since a Build Definition isn't bound to a Team project, but to a collection, there is also no way to configure the Queue to pick up builds from one Team Project before any others.
What you can do is to set a tag on an agent and then assign that tag to the build you want to take precedence. This will exclusively reserve the Build Agent to that specific build definition, causing it to jump in the queue.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
A project in TFS is quite a loose term which does not correspond to a VS project, it's actually used to refer to a product which can contain many branches. The high level project management tools then operate on the TFS "project".
If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order).
Nope, assuming you don't have a custom build then they (the VS projects) don't build in alphabetic order at all, they build in order of dependency. Solutions are built in the order they are returned from the evaluation of the $(SolutionsToBuild) property (this does a wildcard search of the filesystem for .sln files, so maybe that's where your alphabetic observation comes from). Note that dependencies are evaluated on projects within a solution, there is no evaluation of dependencies across solutions.
For the following statements I'm going to assume that you have standard CI style builds gated upon checkin.
If a developer checks in everything at once then the checkin will happen as an atomic unit of work and the build will commence once the checkin is successfully committed. If this is not your experience then I would suggest that you either have funky stuff happening in a custom build, or the developer is checking blocks of work in separately rather than all at once.
Note that this happens per checkin per workspace - if two different developers check stuff in at the same time then whoever checks-in first will trigger the build, and the submission of the second developer will miss the build.
Ok so I have to admit, I'm very new to all of this build automation stuff. But basically what I'm wondering is if there is a way to wire up my build definitions in such a way that if I have a case like so
ProjectA produces ComponentA.dll
ProjectB references ComponentA.dll and produces ComponentB.dll
ProjectC references ComponentB.dll
then when I make changes to ProjectA and check them in, the build process would automatically also build ProjectB, and finally ProjectC, and report any errors.
So is there a way to accomplish this, or should this type of thing be handled somehow completely differently in the first place?
The process you are referring to is the crux of the practice known as Continuous Integration.
TFS does it very well: simply set your build definition Trigger to Continuous Integration and set the Workspace working folder to the parent folder of the three projects. This way, any change in one of the projects will trigger a build.
MSDN: Build and Deploy Continuously
You can use a visual studio solution and use project references between the projects. Then build the solution on your build server.
Our C# solution has a couple of folders that are populated via post-build events (i.e. they are initially empty).
The solution builds fine locally, however when using the TFS build agent, the folders don't show up in the published websites folder.
Any suggestions on how to force TFS to copy the folders over?
This is addressed here: publish empty directories to a web application in VS2010 web project
TFS does not execute the AfterBuild target of your proj file. I believe it will execute the AfterCompile target but this still might not do what you want.
I have used the approach of including dummy files which is simple enough even though its lame.
I've tried the approach of including a powershell script to do some post-publish tasks which works.
More recently I have adopted a convention of including a supplemental MSBuild file that ends in ".package.proj" and added an additional MSBuild execution activity to my Team Build Template that looks for it after the files are dropped to the drop location and then executes it. This provides a simple hook into the Team Build workflow without getting you deep into changing the workflow for a particular build. It's just a single additional activity wrapped in a conditional that looks for the file. If found, execute it.
You could also make a custom build template and use the Workflow activities to perform various cleanup tasks, but it's probably overkill and will increase maintenance on the build templates. Better to keep the customization simple if you can and have it function in a way that doesn't require "opt-out" configuration on builds that don't require the customization. Existing vanilla builds should continue to work as expected after the customization to the template.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.
I am preparing to move my team's source control from VSS over to TFS 2008.
This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.
I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.
Here are my requirements:
When code reaches a certain point, I manually apply a label to it.
This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
Any of these 25 environments can be on any current or past labeled version of the application.
I need to be able to deploy any labeled version of the application to any of the environments.
I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.
I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?
Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)
By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.
see 4.
I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.
Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.
To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.
The custom build task allowed me to get the latest version from a specific branch and label.
Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.
msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.