I'm new to version control systems and have been tasked with revamping our company's version control (small system right now). We have library files that will get updated, but we also need to support older versions of these libraries for different generations of our product. Part of my task is to set up an automated unit testing system that will do nightly checkouts, if newer code has been checked in since the last test run.
You will likely need to keep multiple branches of your libraries in source control, one for each version that will be supported/changed in the future. Each of these branches should have a build definition created to build the code and then run the unit tests against the code. The builds can be setup to run in
CI mode which will build on every checkin
Gated checkin mode (my personal favorite) which won't commit the checkin until the build and test run completes successfully.
Related
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
We have several assemblies that we share over all our projects. Since last year we use NuSpec files to create packages and share them all in a internal feed. The packaging is done as part of the build process (TFS 2015). Versioning is set to automatic, use date and time. The build is a CI build and triggered when merging from the Development branch to the CI branch.
When one wants to use the packages, one has to enable "include prelease" in the NuGet Package Manager to get these packages. This is ok, for time while a package is not completely tested, but ready to release.
Question
What I am looking for is a straight forward way now, to promote such packages, once they've been created and tested, to a release version, leaving the original Major.Minor.Revision but removing the date portion of the prelease version and share that new version in a - ideally the same - feed.
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.
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.