I just downloaded the Automatic Versions add-in for VS here (https://visualstudiogallery.msdn.microsoft.com/dd8c5682-58a4-4c13-a0b4-9eadaba919fe/view/Discussions) and it works great locally, but how do I get it to work with Team Builds? Is there something I should install on the build server?
Firstly, the Automatic Version addin is not called in TFS build even if it is installed on TFS build server machine. In other words, you can't use it to generate incremental assembly version during TFS build process.
Instead, you need to create one custom build process activity to update assembly version, then customize the TFS build process template to add the activity. Please check the following links for the details of the sample build activity and how to customize build process template to use it.
http://www.codeproject.com/Articles/705482/Updating-Assembly-Versions-During-TFS-Builds
http://tfssimpleversioning.codeplex.com/
http://blogs.msdn.com/b/jjameson/archive/2010/11/29/incrementing-the-assembly-version-for-each-build-in-tfs-2010.aspx
Related
How do I integrate InstallShield/Wix/IsWix with TFS? I wish to auto generate setup files during successful TFS checkin/release?
I am comparing InstallShield with Wix and IsWix! to choose the right candidate for upcoming product development.
Tools Used
v.Next Builds
Team Foundation Version Control
Update from InstallShield support team
To integrate InstallShield with Team Foundation Server, install InstallShield on each machine that u want to be able to create, update, or build InstallShield projects.It should also be installed on a machine that is designated as a build agent for InstallShield projects that are stored in Team Foundation Server.
NOTE: The Standalone Build is a build engine that enables you to build InstallShield projects without installing the full version of InstallShield on a build machine.If you have the Standalone Build, you can install it on a machine that is designated as a build agent for Team Foundation Server."
I have very limited experience with InstallShield, but I can advocate for WiX. Recently they added a no-install option that allows you to build WiX project by just adding a few files along to your sources.
WiX code is an XML dialect and it is simple to generate, but the simplest pattern is to write a Product and a Project file and let Heat generating the remaining code you need for a simple install.
At a high level you need to create an .ISPROJ (MSbuild ) and .SLN for your .ISM. In the ISPROJ you'll want to write some code to regex parse the build number and generate a random ProductCode for major upgrades.
You'll add a build vs sln step to your build and tell it to use 32bit MSBuild (InstallShield doesn't support 64bit).
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/variables?tabs=batch
http://helpnet.installshield.com/installshield22helplib/helplibrary/MSBuild.htm
You'll need an on-prem build server and install the InstallShield Stand Alone Build engine one it. I'd go ahead and install the Automation Interface also as you don't know when you'll need it some day.
Currently, we are using TFS 2012 and we have a heavily customized build process as described below.
1. Build the source
2. Run an EXE as console to host WCF services
3. Restore databases on local sql server
4. Run functional test
5. delete databases
6. close the exe started in step 2.
7. Create an Installable exe using WiX ( Wix with custom bootstratpper)
8. Update version number file to TFS
Now we want to move to Visual Studio online from onpremise. Trying to setup a build process with Private Build agent. I have created an VM , installed and registerd agent. I do see agent name back in website.
When I go back to Visual studio and try to create new xaml build definition I am getting below error.
TFS22501: Creating a build definition requires a build controller be defined for this team project collection. There may not be any controllers configured or you may not have permissions to view them. contact your team foundation server administrator.
can somebody please help ?
If you're using XAML build, you have to use the old-style XAML build controller/agent. The VSTS agent is for the new build system.
I would strongly recommend migrating your builds to the new build system as part of your migration to VS Team Services, as the XAML build system is effectively dead.
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
My current TFS build process just build my website project and output all the files, such as assemblies, web.config, etc.
From here, I learned how to create a web deploy package with MSBuild in command line.
But I want to know how to insert this package step into my current TFS build process.
Thanks for any insight.
Create your release package by creating a publish profile through Visual Studio. For this example mine is called Release. this will create you a Release.pubxml file in a folder called Publish Profiles, under your project, check this into source control.
Then in your build definition, under the process tab.
Expand the 02. Build > 5 Advanced or similar depending on the version of TFS you are using, add the following to the MSBuild argument text box
/p:DeployOnBuild=true;PublishProfile=Release
ensure the PublishProfile has the same name as the one you created earlier (Release)
this will create your deployment package as part of the build