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
Related
I want to do continuous integration and deployment in Azure Data factory. I'm not able to find any specific document explaining this.
How can I do it or where can I read about it?
To build your project, you can use msbuild - just like it's done in Visual Studio. It will validate syntax, check references between json configurations and check all dependencies. If you are using Visual Studio Team Services as CI server you can use Visual Studio Build step in build configuration to do it. However, it requires to install ADF tools for VS on build agent machine.
To deploy, you can try:
Powershell. For example, you can use Set-AzureRmDataFactoryV2Dataset to deploy datasets. There are similar commands for all other configurations and for version 1 of Azure Data Factory as well.
If you are using VSTS, you can try this 3rd party extension. It allows to deploy json configurations and start/pause pipelines. I'm not sure if it works with ADF v2.
You can use the VSTS GIT integration with ADF v2 UX to do continous deployment and continuous integration. VSTS GIT integration allows you to choose a feature/development branch or create a new one in your VSTS GIT repo. You can work in your feature/development branch and create PR in VSTS GIT to merge your changes to the master branch. You can then publish to your data factory using ADF v2 UX. Please try this and let us know if this doesn't work for you or you face any issues.
I have nodejs app. Can I deploy it to azure app service without VS or other big IDE?
So, I want an easy way to select branch what I need push it to azure and run default command for nodejs.
I'm stuck with it, because all of solution it is use VS.
You can deploy to azure app service by using Azure App Service Deployment step/task. For example:
Create a build definition
Add related step/task to build your project
Add Azure App Service Deployment step/task (Can publish using Web Deploy or upload files directly)
Select Triggers tab and enable Continuous Integration
Specify repository and branch filters
After that, the build will be triggered if you push changes to target branch.
Related article: Define a continuous integration build for your Node.js app
Regarding run command for nodejs, you can refer to this thread by using kudu API: Include node modules in azure deployment via VSTS.
This can be done. Take a look at the build and release functionality in Visual Studio Team Services.
With VSTS Build, you can trigger a build and push to an Azure Web App automatically on a Git check-in for a particular branch, or you can manually trigger the build and push.
Take a look at the Azure App Service Deploy task in VSTS build.
Note that since VSTS is pulling from your Git repo, it doesn't matter what IDE you use to actually develop your app with.
Also, VSTS is free for small teams and a single deployment pipeline.
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..
Visual Studio 2013 has a publish wizard for Cloud Service projects that packages and deploys a cloud service based on settings persisted in a .azurePubxml file.
I'm setting up automation of this process on a CI server, and want to leverage this functionality within MSBuild, but I'm unsure if it's even possible.
I have found a lot of articles that talk about shelling out to a PowerShell script and using a custom MSBuild target file to do the deploy, but that seems like a duplication of information that I'd rather not delve into.
Given that I have the Azure subscription credentials installed on the build machine, VS 2013, and Azure SDK 2.2, can I invoke the same mechanism that VS 2013 uses in the publish wizard to package and deploy my cloud service?
Currently, using MSBuild with the publish target, I can package the service into a .cspkg file, but I cannot figure out how to trigger to package/deploy based on a profile (.azurePubxml file) that defines the VS build config, and all of the Azure settings.
So, as you pointed out, the default targets will only give you a package. From there, Visual Studio is publishing things using their own infrastructure. Publishing the build from a CI server is considered something external to actual build process and rather something that is part of the deployment process.
If your CI technology has support for PowerShell then it's as easy as automating the Windows Azure PowerShell cmdlets to do your bidding. There's a nicely detailed article on how you might do this with Team Builds in TFS here on MSDN.
We have built a small MVC4 application using Azure Cloud Services. It has been deployed through Visual Studio. Now we are going add a test environment where the application should be tested, before being deployed into production.
I would like to have our CI server to build, test and create a deployable package, This package could then be deployed to any environment, providing correct configurations.
But I have not found a convenient way to do this. It is easy to build a package for a specific environment, with configuration transformations for .config and .cscfg files.
Is having the CI server to build a separate package for each environment the way to go, or have I missed something?
There are ways described how the web.config could be modified when the WebRole is starting, but this feels a bit hacky, and not the way the guys at Microsoft intended when creating Cloud Services.
Using the CI server to deploy the specific configuration has been the easiest in my experience. I think using the Visual Studio "Build" section in Team Explorer is what your looking for. We use Team Foundation Service as our Continuous Integration and Continuous Delivery server. In Visual Studio we've created Production and Testing build configurations. In the Build tab we've created a Continuous Integration Build which will kick off unit tests on every checkin, and a Continuous Delivery Build That will deploy newly tested checked in code on a regular schedule. These Build Events can be set to use a specific (Production/Testing) build configuration.