We work with TFS 2015 and it works really great. We have two different build sets one for our production environment and one for our test environment. We also use CI. Our current workflow is that we "Queue build..." and then everything is done automatically.
What we would like to accomplish on our production build is one of the following:
On "Queue build..." the person has to acknowledge the build or
You have to somehow start the queue manually, so the queue build doesn't start automatically
Don't use builds for deployment. If you're on TFS 2015 RTM or Update 1, upgrade to TFS 2015 Update 2 (or, ideally, TFS 2017 Update 1). Starting in TFS 2015 Update 2, there is a Release hub that has exactly the kind of capabilities you're asking for. It allows you to define a release pipeline for the binaries generated by a build, where you can put optional approval requirements in place prior to a deployment occurring on a given environment.
Related
We installed the newest TFS Server (TFS 2018 Update 2) which should run xaml builds.
After the update, we started our agent, but our xaml-controller is still offline and I don't know how I start this again..
Any ideas what we can do?
Yes, you can now upgrade to TFS 2018 Update 2 and continue to connect
your XAML controllers and run XAML builds. When we removed support for
XAML build in TFS 2018 RTW and Update 1, some of you could not upgrade
due to having legacy XAML builds, and we want to unblock you. Although
TFS 2018 Update 2 supports XAML builds for your legacy builds, XAML
build is deprecated and there will be no further investment, so we
highly recommend converting to a newer build definition format. See
the Evolving TFS/Team Services build automation capabilities blog
for more information about XAML build deprecation.
When you upgrade to TFS 2018 Update 2:
If you have any XAML build data in your team project collection,
you'll get a warning about the deprecation of XAML build features.
You will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds.
If you need to create new XAML build agents, you’ll need to install
them using the TFS 2015 build agent installer.
XAML Build Controller/Agent info is now under Additional Tools and Components > XAML Build Configuration in the TFS Administration Console. Make sure your build services on the same server as your application tier. You possibly didn't re-configure your XAML build services after the upgrade. Try this and then check again.
Thanks #PatrickLu-MSFT!! through your help, we found a workaround.
Now we use one server for the Source Control etc. (TFS 2018) and another server only for the xaml-app-controller with TFS 2015.
So we can build our projects, and have time to create new build definitions.
In TFS 2015 update 2, is there a way to copy release definition steps from one environment to another, or from one def to another, or within an environment (to make a clone)? What about multiple selection? Drag and drop only works within an environment, and Ctrl+drag doesn't seem to be supported.
In TFS 2013 Windows-based release client, it was perfectly possible.
I don't have TFS 2015.2 to test your scenario, but I have tested in TFS 2015.3. In TFS 2015.3, you can clone environment, but can't clone release definition. Check the screenshots below:
I also tested in the newest TFS15, you can both clone environment and clone release definition. Check the screenshots below:
So, you can consider upgrading your TFS, then you are be able to clone environment.
Our development team uses Visual studio 2013 Pro along with TFS 2010. We need the following abilities for our continous integration / delivery initiative:
1. Automatically build our web project on every checkin.
2. Automatically deploy green builds to development and/or test environments.
3. Provide build/deployment notifications via email.
Extra Credit: Run unit tests with each build.
We don't have a budget, the reason Jenkins is appealing. The setup is new to me and not sure how the pieces fit and what other tools are needed to preform the tasks above?
If you have MSDN subscriptions, you can use TFS for free. TFS 2015 can provide all these features. TFS 2010 can provide most of this as well.
Use a gated checkin or CI build definition in TFS (2010 and 2015) to automatically build on checkin and run tests. The build definition has the option to run tests as part of the build.
Use MSDeploy to package up your components into an automated package. Most people don't know you can use it for more than web applications. (For example, databases)
TFS also provides email alerts on many events.
Regarding automating the deployments, we used separate TFS (in 2010) build definitions to trigger deployments to each environment. Now we use TFS 2015 which supports release definitions that adds many more options.
I would like to upload on my TFS 2015 some of the build tasks that are available here https://github.com/Microsoft/vso-agent-tasks.
I do have a problem with certain task as they do require a minimum agent version of 1.89.0. My build agents are 1.83.2 version.
Now, the question is, how do I update my agents for a given pool? If I do right click the agent pool on my TFS and choose update all agents option, nothing happens. I suppose because the latest version of my agent available on TFS is the 1.83.2.
Where can I find the latest version of it and how do I update it?
Note I'm working on premises TFS 2015 and not VSO.
Thanks
If you right-click the agent pool and choose "Update all agents", it will upgrade the agents to the version of the on-premise TFS server. For instance, if you initially installed some RC, and upgraded the server to RTM later, some agents might have lower version. Otherwise, as you mentioned, nothing will happen because all agents are up to date.
VSO has a different release model and updates/fixes to its agents are continuously delivered. That's why the version is constantly growing.
Technically it might be possible to grab the source code of the latest VSO agent tasks, and push it to the on-premise version of TFS 2015. However, it is considered an anti-pattern, and the behavior is undocumented and unsupported.
Let me quote build vNext developers from this discussion (see the bottom of the thread):
That is not a supported option. It is very likely that the agent we
have in VSO will not work with the on-prem server. You must use the
version of the agent that ships with your server.
And:
The behavior is undefined/untested. It may work, may not. The design
is for agents to get pulled forward via an auto update process
downloaded from your service. The auto update process may alter
configs/layout on disk, whatever. That future agent might call REST
apis that don't exist, etc... The primary focus for agents is on
forward compat so they can lazily get upgraded (via task minimum agent
demand, on restart or eventually a scheduled job).
Same answer as #Yan, but putting this here because the following error came from nowhere - so I think Microsoft updated the minimum requirements this week.
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
Agent.Version -gtVersion 1.95.0
For your own hosted agent just right click on the queue, or click the ... icon.
I had to restart the agent service after a few minutes as it didn't seem to want to by itself. Give it a chance to update properly before doing this.
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.