We have a build server running the new TFS 2015 build agent in an agent pool. I have looked and cannot find a way to 'increase' the number of consecutive builds to run.
Basically, I would like to have our build server be able to build two different requests at the same time. Is this possible?
Unless you are using different agent pools, you can set up multiple TFS Build Agents on one build server (machine). If you are putting the agents in the same agent pool, your demand is not possible. There is a clear picture show in how are agent pools and queues organized?
From the above picture you can see unless they are in a different agent pool, there is no possibility to build two different requests at the same time.
Moreover, there is also a parallel build in the vNext build definition. However, this parallel build only has support for different platforms by different build variables.
Related
I originally felt this question was for Software Engineering, but they've closed it as off topic and sent me here, so here I am.
One of the biggest time sinks when doing the odd piece of DB development is setting up the environment locally, often my process goes like so:
Get database
Publish db server
Publish db
Load test data
Repeat for any dependencies (can go 3-4 levels deep)
This is a bit of a pain really, and can take a while, and I was thinking if there are any ways to automate this.
We make use of ADO, and through ADO we run builds that deploy our changes and load out test data to make sure we haven't broke anything. Now I imagine ADO follows a very similar process to myself like above, and reviewing the build it looks something like so:
Now, I'd love it if I could get access to the script that runs this, so that when I start development, it gets rid of all the above down-time of setting up the environment.
Does anyone know a way to do this? Or perhaps have any other recommendations?
No, it's unable to copy the build to run locally. They are all based on the existing tasks (see Build and release tasks and azure-pipelines-tasks ).
However, you can try to develop your own scripts by calling the corresponding tools for each step, then combine them together.
Alternately you could setup a private agent on your develop machine, then you can build with this private agent with that build definition.
Another way is setup a on-premise Azure DevOps server, thus you can export the definition from your Azure DevOps Service and import to the on-premise Azure DevOps server to use the definition directly.
I am trying to set up a job as part of a software deployment that requires backups of two SQL Databases housed on separate servers, these backups needs to be initiated at the same time. I am using deployment group jobs for all of the other steps in my release pipeline, these are agents running on servers in my organization (non-cloud).
I have a release pipeline where I am successfully backing up one database as part of a software deployment. I have a separate deployment requiring the backup of two separate databases simultaneously. I have not been able to find an option in devops to either run two tasks at the same time, or run two jobs at the same time. Every option that I have tried simply runs things in sequence. Does anyone know how to accomplish running two or more tasks / jobs in parallel in a release pipeline?
Tasks in an agent phase in a release pipeline does not currently support dependencies like build pipelines, so will not support parallel agent phase execution. Tasks in a deployment group phase will execute in parallel on every server in the chosen deployment group that matches the given tag if one is provided. The tasks defined in a deployment group phase will execute the same on all machines, so it is not possible from the pipeline to pass in unique parameter values (DB-name/Credentials) specific to server for deployment groups. You'll have to manage those unique parameters a different way, possibly as environment variables on the server that can be referenced by the release task.
So, if you have two DB server configured with the deployment group agent with the tag "DB" and create a deployment group phase with your backup task that targets that deployment group for servers with the DB tag ... those tasks will run in parallel on the two servers.
I am initiating a huge team to use SSRS for their reporting purposes. Previously I used to develop the reports and send it across to the DBA to implement it, but my recent posting is into a company where they Build once and deploy many process.
I would like to know how reports I developed on DEV environment be pushed into the upper environments with an automated build process.
Thanks
Does anyone have any advice or techniques for deploying SSIS packages to the Integration services database.
Basically I maintain a number of SSIS packages that need to get deployed to several environments (dev, test and production), there is a need to change the individual database connections as well.
I would like to automate the process of deploying them to these environments, so it can be included in a full application deployment that can be done by the server admins.
I came up with a method for configuring packages for different environments using a single SQL Server configuration table (assuming all environments can connect to the configuration server).
http://www.sqlservercentral.com/articles/SSIS/66426/
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.