In my build definition I deploy to multiple Azure cloud services and would like to deploy in parallel, however the build definition in 2015 doesn't allow steps to be run this way.
Is there a way I can have three groups of steps (each with a Visual Studio Build and then Azure Cloud Service Deployment step) running in parallel.
This will save me huge amounts of time in our CI/CD builds allowing for faster feedback from the builds.
Instead of deploying from a build, deploy using the Release hub.
You can define multiple release environments, then use the "Deployment Conditions" option to set multiple environments to deploy at once. However, you would need one agent per environment so that the agents can run in parallel.
Currently, there are not parallel tasks in the VSTS build and release process. However, there is a uservoice item for it. Please vote for it!
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/13481574-add-ability-to-run-build-steps-in-parallel
Related
Is it possible to pull / clone bitbucket repository within Azure Logic Apps?
I am curious if it is possible to set up some backend tests within Azure Logic Apps. So to pull repo with tests first and then execute them within CLI. I see that there is bitbucket connector in Logic Apps but there is no option to pull the repo. Or should I check some custom connector to run commands from hand like "git clone" etc. - if yes which one?
Azure Logic Apps is a cloud platform where you can create and run automated workflows with little to no code. By using the visual designer and selecting from prebuilt operations, you can quickly build a workflow that integrates and manages your apps, data, services, and systems.
From: What is Azure Logic Apps?
The key concepts here are "little to no code" and "prebuilt operations". Building your code with a CLI and running its tests is not something Logic Apps is targeting. It would also make executing Logic Apps a LOT more complex on the Azure end, since it would mean installing any and all frameworks, tools, etc. that are needed for building the code/running the tests.
If you look at Bitbucket actions that are supported, you can kind of make out that they're all API calls.
What you're looking for is available for free with GitHub workflows
A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
or Azure Pipelines.
Azure Pipelines automatically builds and tests code projects. It supports all major languages and project types and combines continuous integration, continuous delivery, and continuous testing to build, test, and deliver your code to any destination.
Potentially interesting read: Build Bitbucket Cloud repositories.
We are using TFVC as VCS, our repo is located in Azure Repos, we use Azure DevOps for CI/CD.
There is a pipeline building changes of Main branch and "Gated check-in" option is enabled.
We use hosted agents deployed on our build servers. Currently there are 3 build environments and 1 agent is deployed to each build env. As there are many developers working on the project - many concurrent check-ins became a bottleneck, that's why we have now 3 agents in a single agent pool, the pipeline has 1 job and it is using agent pool with 3 agents.
The problem is that when several developers check-in changes only 1 build is running, all other in a queue have to wait until it finishes, despite the fact that other 2 agents are online and Idle in the same pool.
The build is queued with the message "Job is pending". Interesting thing is that if we run the pipeline from azure devOps they run concurrently, but when developers check-in changes from Visual Studio - they're queued.
This is due to the "gated checkin" option being enabled. Gated checkins do not run in parallel.
This answer provides more details.
In short, gated checkins take the latest changeset in the branch + the code being checked in and then build the code. If the build fails then the checkin will fail. If you want to have parallel builds then you need to disable gated checkins and use a CI build instead.
I am trying to create a deployment plan for my web application in Azure which can support 2 environments (Dev/Staging). Basically, I want the code checked in by developers to be deployed to the Dev machine end of the day. And then the latest Dev changes to be merged with staging branch and if no merge conflict happened a new publish goes to staging machine. Can anyone help me where to start and what feature in azure i can use to server this?
You could use Azure Devops to trigger scheduled builds (at the end of the day) to perform the routine you are describing. you could also use releases and trigger them automatically from the builds that happen on a schedule.
You would also need to deploy vsts agents on the machines or allow for vsts agents to somehow talk to the machines to upload code to them
I have set up Azure continuous deployment from a branch in my Visual Studio Team Services GIT Repository. Everything is working fine however I would like to run a few gulp tasks before the actual deployment takes place. Is there a way how I can do this?
Azure provides continuous deployment out of the box through the use of several sources of your code. What you will need will be more in the side of continuous integration, running tasks and flows to build the code.
There are many ways and tools of doing continuous integration, nevertheless the most compatible to do this in Azure would be within the build and release parts of Visual Studio Team Services.
Within your Azure subscription you can setup this following the next steps(it seems you have already setup your code in Visual Studio team services, then you can skip to step 3):
Creating a VSTS project
Putting your code in a Git Repo inside VSTS
Creating a Build definition
Adding your tasks from the Catalog
Adding and configuring your Gulp Tasks
Deploying the build to Azure
I have a Visual Studio 2013 solution with 3 cloud service projects (1 Web Role, 2 Worker Roles) and a set of nUnit tests hosted in Visual Studio Online.
Through Azure portal, I've setup a continuous integration build that builds and deploys my solution on checkin. Azure, however asked me for a single Cloud Service to deploy solution into (although my project contains 3 of them) and obviously, the build only deploys one of the cloud projects (presumably the first one it finds). How can I make it deploy all three?
I'd rather not create three different builds.
From my experience, you cannot deploy all of your azure projects within your solution to azure at the same time using the VSO CI builds. If you look at your CI build definition under process you'll see that you can only specify one cloud service name to deploy to. We ended up having to create one solution, with one azure project, and one CI build per cloud service. We use the staging environments as a temporary deployment destination until all of our services are built/deployed, then swap them all at the same time to achieve a somewhat seamless/instant update.
Hope this helps.
I was able to get this to work with the new VSO VBuild Next System in TFS 2015.
You are able to build a specific *.ccproj cloud service project and from there use a specific task to publish to azure.
This allows me to have multiple cloud services and multiple web roles in the same solution.
You should also be able to build multiple cloud service projects and setup multiple publish tasks, all from the same build definition.
From MS...
We've built a brand new scriptable build system that's web-based and
cross-platform. We believe all new and most existing customers should
use it instead of the XAML build system.
More info:
https://msdn.microsoft.com/Library/vs/alm/Build/overview
Here is a view of my build tasks..