We have a solution that contains (among other things) an Azure Functions project, a Web application project and a WCF project. The solution is hosted in VSTS as a Git repository.
I have used the "Configure continuous integration" button in the Azure portal > Function app settings to select the repository, but when the build is triggered and deployed, according to the logs generated it's trying to deploy the Web app rather than the Functions.
How can I configure a CI build to deploy the Azure Functions project from that solution?
You should be able to customize your deployment and set the target project as documented here.
More specifically, you want to use the project configuration to point to your azure functions project/folder (using a deployment file, or config setting)
Related
I am planning of using Visual Studio TFS server for Continuous Deployment.
I have few projects which are related and when a particular project is updated it might rigger a change in that related project
E.g. Web Project and a Middle Layer API project
Now when I follow CD , how can I ensure that Middle layer API project is deployed before the Web Project is deployed
You have to create only one release to deploy your two related projects.
Choose one of them as the main artifact. Let's say the web project.
At the artifacts page in the release configuration, add your middle layer project as another artifact to the release.
Now that you have your two target projects, setup your release pipeline so that you add the steps to deploy your layer project before your web project.
I have visual studio solution with 2 web projects. The source is in VSTS and the apps are hosted in Azure. I have build and release management setup to automatically deploy to Azure.
So every time I check in something, 2 releases are triggered, one for each web project. Is there any way I can separate the two? The web project should only trigger for a check in on that folder and the api trigger for a check in on that folder?
You just need to change Path filters for specific path of each web project path. More information, you can refer to Build definition triggers.
I am using the new VSTS release management to deploy my website to Azure web app. All I want is to transform one connection string for QA environment. I am finding it hard to get answer for that. Any help is much appreciated.
I don't want to create tokens in my web config file because I want to use the config file as such in my local environment.
You can also use the VSTS variable which contains the connectionstring to deploy as a connectionstring to an Azure WebApp.
This looks like a shameless plug for my open source VSTS task. But it is a clean and easy solution for your problem. My task can be used to deploy appsettings and connectionstrings configured as variables in VSTS to deploy to an Azure webapp. Without changing the web.config.
Take a look in the marketplace to install it in VSTS and for the documentation: https://marketplace.visualstudio.com/items?itemName=pascalnaber.PascalNaber-Xpirit-WebAppConfiguration
Storing connection strings (other than the local dev ones) on a source control is far from being a best practice from a security perspective.
The build/release management system allows you to have secret variables and/or services endpoints you can reuse in your flow.
However you should look into the publish commutator in the build step (MSBuild arguments), that will ask to visual studio to do the publish and apply transformations from the config transform files and publishing profile.
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"
This is what I put in my MSBuild Arguments on a Visual Studio Build task on my build definition and it works like a champ:
/p:DeployOnBuild=True;PublishProfile="$(BuildConfiguration)" /p:publishUrl="$(Build.ArtifactStagingDirectory)" /p:DeleteExistingFiles=True /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish
Note that I have BuildConfiguration as a variable which corresponds to UAT or Release or Dev for example. The PublishProfile corresponds to a Publish Profile you've set up in your project/solution. (So, if you name your Publish Profile "Hey-Go-To-Dev" then you'd put "Hey-Go-To-Dev" in the BuildConfiguration (or a new variable you can set up).
Anyway: This will execute your publish profile and do any related transforms in your web.config file(s).
Godspeed.
I'm trying to create web deploy packages through visual studio team services.
Currently, I have created a web deploy publish profile in Visual Studio. I use MSBuild in Visual Studio Team Services to build the solution and create a web deploy package. I then zip the package and save it to a shared location. However, the issue with this approach is that it does not provide me a way have a same build for different environments. Let us say, I created a web deploy package for DEV environment. Then when I have to deploy the build to SIT environment, I would need to build the solution again and create a package. This way I would have different builds for different environments. I would like to have the same build get promoted to different environment for better traceability and maintenance.
One way I feel I can achieve this is to have a separate build definition for just building the application and save the DLLs to a shared location. I can then have a separate build definition which takes the build from shared location and create a web deploy package from the build. How can I achieve that on VSTS?
Other way possible is creating a label when any deployment happens one environment, say Dev environment. To do the deployment in SIT I can use the source code with same label and then use MSBuild to create a web deployment package. Is there any way to achieve this through VSTS with/ without creating a separate build definition of each environment?
Any other suggestions than above?
You can use VSTS Release Management to deploy your deployment package to different environment and use "Tokenizer" task in Release Management Utility tasks to update the config file in the package base on the variable for different environment configurations.
And you can also try with Web Deploy Parameterization.
We use Hedgehog Team Development for Sitecore to manage content items and also want to use it for content deployment.
I am trying to create a TDS build configuration that should deploy TDS items to a remote dev server. Dev server isn’t on my local so I don’t know what I should mention in “Sitecore Deploy Folder” field.
What I am trying to achieve is when any developer / TeamCity builds the TDS project in dev configuration the TDS items should be deployed to the dev site. I can’t create this configuration from the dev server as we don’t have visual studio on the dev server.
I even tried putting the path from the server (this path doesn’t exist on my local from where I am try to set the configuration) but that doesn’t work.
Any directions on this would be much appreciated.
Thanks.
On the Build tab of your TDS project, there are two fields.
Sitecore Web Url This is what TDS will use to connect to the server component to deploy your items.
Sitecore Deploy Folder This is used for two purposes, one to install the aforementioned server component ("connector") and to deploy the output of your web project.
For deployment to a remote server, the Sitecore Deploy Folder needs to be a UNC path to the web root on the server (e.g. \\devserver\share\path-to-webroot), and whatever identity is running the deploy needs write permissions on that share.
I believe TDS only uses this path for deploying the "connector", which consists of the _DEV folder with the web service endpoint and some libraries that are placed into Website\bin.
If you are choosing to use the Deploy feature of TDS for CI, ideally you would deploy the "connector" manually the first time and although there is no use in setting the Sitecore Deployment Folder anymore TDS would not deploy with it blank. Your best bet is to setup a share on a server and use the share path for that setting (i.e. \myserver\share).
As a side note, check out the TDS package installer that comes with the app under C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2013). It is possible to set the TDS projects to generate *.update packages for code and content and automate their deployment or deploy them manually - just another way of implementing the CI.
I am using TeamCity as build for Sitecore and TDS deployments. Have a few different configurations depending on packaging needs. (update packages vs. webdeploy, etc).
Our typical approach to this is to create the MSBuild XML file for the configuration directly, which allows me to control the CI builds and deployment distinct from local developer builds.
In this case, the active configuration during build is set to DEV-CM, or TEST-CM, depending on the environment, and I pass in MSBuild parameters for:
IsDesktopBuild=false
GeneratePackages=true (TDS project properties are set to generate separate code/file packages)
SitecoreWebUrl=ht tp://[host]
SitecoreDeployFolder=\[server][share]\website
In visual studio, the DEV-CM and TEST-CM configuration targets are created and configured for the TDS projects to enforce Deployment settings, multi-project packaging dependencies, etc.
This sends the configuration to TDS's portion of the build, generates the packages (which I have published out as TeamCity artifacts) and performs the TDS deploy to the target URL and target UNC.
I would encourage the route of separate build XML files and specifying that XML file as the target script in the TeamCity build step.