I have a question about forcing/permitting where the TFS Build Cleanup jobs get run. This is not a question of when they are run, but a question of how to direct TFS to run them on specific build server(s). First the background:
I manage a small farm of on-premise build/release servers, all connected to an on-premise TFS2017 Update 2 system, with agent 2.117.2 installed on the build/release servers. One of these build/release servers exists in a separate domain (our production domain) from our development domain, and purposely only has read access into the development domain.
Our builds, and development releases occur on the servers in the development domain, and those builds are directed to those build/release servers via build/release demands in the configurations. This all works well.
Its only been recently that we've had a release server in our production domain, and with that has come the realization that TFS is 'randomly' choosing an available server on which build cleanup jobs are to be run. This random allocation to an available build/release server is a problem.
While the cleanup jobs could run on any build/release server in the development domain without problem - they can not run on the release server in production as that server only has read access into the development domain by design. As a result, all triggered cleanup jobs on the production release server fail.
Is there a way to limit which execution agents the TFS Build Cleanup jobs are able to be triggered on? Providing R/W access to the prod release server is not a desirable workaround to this problem.
Related
I currently manage a TFS 2018.2 TFS server for 100 users that have Visual Studio Enterprise. On our build and release resource limits tab we show that we have 103 release pipelines.
I am acquiring the management of another TFS 2018.3 server, but the users only have Visual Studio Professional. As such their release pipelines are limited to 1 pipeline.
I have read the page at: https://blogs.msdn.microsoft.com/tfssetup/2017/11/14/understanding-build-and-release-pipelines-visual-studio-team-servicesteam-foundation-server/
From that information I believe what I am reading is that this number only affects Releases running in the TFS Release pipeline, and not build running in the build pipeline. #1 : Did I interpret this correctly?
Second, we are considering upgrading our server to Azure DevOps Server 2019. On this page: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops-2019&tabs=browser
There is an important note stating as follows:
Starting with Azure DevOps Server 2019, you do not have to pay for self-hosted concurrent jobs in releases. You are only limited by the number of agents that you have.
Therefore, if we do upgrade to the on-premises version of TFS Server, we can run all of both builds and releases currcurrently for which we have agents installed. #2 : Can you confirm this is also correct?
I tested and confirm your interpretation for the documents in above links is correct.
With TFS, you only need pipelines for deploying releases; no pipelines are required for builds since unlimited concurrent builds are included with the TFS server license.
I tested on tfs2018 multiple build pipelines could run concurrently based on how many on-premise agents I have installed. But i can only run one release once a time.
Starting with Azure DevOps Server 2019, you do not have to pay for self-hosted concurrent jobs in releases. You are only limited by the number of agents that you have.
I also tested on vsts2109, both build and release pipeline can concurrently based on how many on-premise agents I installed.
We are using a server running Windows Server 2012 R2 for our TFS work item management and source control.
But we want to set up a dedicated Build server.
We are running TFS 2018 Update1.
I've downloaded the latest available Build agent and ran the script 'config.cmd' from the dedicated Build Server.
In previous versions of TFS you were at least supposed to run the TFS Installation Wizard if I'm correct to configure the Build Service. But this changed since TFS 2015.
But where can you see that my dedicated server (that I used to run config.cmd) is actually used for executing the Build process?
I cannot really find information on how to install and configure multiple servers for running TFS.
as far as I know running the config.cmd is enough. The machine where the script is executed will then register with the server instance - during the configuraiton you had to specify the TFS Server URL right?
On the Server side, you can go to the Agent Pools (where you initially downloaded the Agent Configuration). After clicking on the Agent Pools on the left-hand side you should see all Agents registered to that Queue. To which Queue your agent belongs was as well specified during the configuration on the agent itself as part of the config.cmd.
If you want to add more agents, you can simply run the config.cmd on other machine and register your agent with the same server instance. It is even possible to have more than one agent on the same physical hardware if you want that.
I am creating a build using the new TFS 2015 Build definitions. I have msbuild tasks as well as npm/gulp tasks. I am looking at using variables to allow me to build and deploy to each environment, with DEV being the only one that runs on check-in. However, I don't want anyone to be able to start a deploy for production. How would I go about limiting the users that can start a deploy to production? I'd prefer to only have one build definition, for maintenance.
Use the Release hub capabilities for deployments and create an approval workflow for your environment pipeline.
Is it possible to configure an on-premise TFS 2015 (Update 2) instance to make use of the hosted agent pool in a Visual Studio Team Services account?
All our builds / releases are currently done in-house, but to simplify the process of automated testing using clients and services hosted in Azure, we would like to move to VSTS-based agents (initially just for the release tasks, but possibly for build tasks later on).
The real desire here is to have our automated tests run outside our local network so our connection is not saturated with all the chatter of set-up / test run / tear-down against our cloud-hosted applications. These UI tests happen as part of our release process (using TFS Release Management).
I'm not 100% sure that configuring Releases to run on a hosted agent is the right approach to the problem, but it's what we're investigating for the time being anyway.
Hosted Pool currently works only with VSTS.
The only option for you at this point of time is to setup a VM with VSOAgent and configure it with TFS On-Prem. This will require your TFS to be exposed to internet (or just to the VM) so that the agent on Azure can configure itself.
Source - I am a Dev for the Hosted Pool Service.
Using a single server that is only contains one Jenkins building for dev, test, etc.
Using separate Jenkins on each dev, test servers to build and run tests.
Edit ;
this is an explanation of step by step our deployment and release model
Our server side developers develop and commit/push their code to github.
CI server that Jenkins is located in poll SCM and fetch changes than build. (within CI server), run unit tests.
After building process and deploying artifacts to repository server (artifactory server)
Then CI server starts to deploy latest successful build into Development Server.
then client mobile developers can develop on latest successful snapshot build of server side.
These are our standard deployment process.
By the way,
We are also doing test deployment to test server via CI server with another different job on Jenkins (same CI server) but, this is handling/triggering by manual.
Preproduction and production transitions are done by manual also. (preproduction and production are different servers of course)
Questions;
Integration tests should be run on test server. How can i figure it out by building system on remote CI server instead of building system on the same machine (test server) ?
As a further step, what would the best option be to construct a Continuous Delivery system. ?
Thanks
A good approach is to have a single CI system that builds the system continuously as development makes changes. This build will on each build run all the unit tests as well and result in some kind of package that can be deployed. That can be further connected with automation that deploys and runs other tests or it can be used by e.g. testers to further test the system.
Depending on your release model and branching strategy as well as type of system/product this basic setup can be adjusted to fit your needs.
If you want more details please explain what you build and how you release/deploy.