I have a build definition set up that successfully builds on each check-in and deploys to the cloud (Azure). However, I'd like to know how to modify it if I wanted it to build, but not actually deploy to Azure. Just build after the check-in, make sure nothing breaks, and that's it. I've tried searching around and modifying MSBuild arguments, but to no avail. This should be easy. What am I missing?
These are the MSBuild arguments I have plugged in. The last two (DeployOnBuild and CreatePackageOnPublish) don't seem to matter at all...not sure /t:Publish is making any difference either
/t:Publish
/p:TargetProfile=Cloud
/p:DeployOnBuild=false
/p:CreatePackageOnPublish=false
Thanks!
The key is to use the correct build process template:
Right click the build definition -> Edit Build definition
Process tab
Up at the top there is a section for the Build Process Template
Show Details
Select "DefaultTemplate" from the dropdown
The options available in the process tab will be different than the AzureContinuousDeployment template I was using. I didn't need any MSBuild arguments (though you might depending on how you named your service configs).
I had never noticed the template before. Most people probably just assumed I was already using the default one!
Related
I have added few arguments to the existing Build Process template, so I can pass those arguments to Powershell Script which was invoked as part of build customization. I had defined those values for arguments under build process tab but somehow those arguments value are not showing up whenever build was queued.
Please help..
In TFS 2013, the default build process template has included run script and add arguments, you can use it directly instead of customizing the build process template to invoke powershell scripts:
You need to add arguments in Process Parameter Metadata Editor, then you'll see these arguments on Process tab in build definition. Refer to this blog: http://www.ewaldhofman.nl/post/2010/04/27/Customize-Team-Build-2010-e28093-Part-2-Add-arguments-and-variables.aspx
Make sure you have checked in the custom build process template, and select the correct build process template in your build definition.
You can go to TFS web access to check Diagnostics log to see whether you can see the arguments you added. If you can see them on
Web Access, then your customization is correct. If you find you can
see the arguments on web access, but not in VS, try to change the
BuildMessageImportance of the variable to High.
I have an Azure Web application that I checked into TFS yesterday with no issues. Upon checking in, the resource manager will inject our nuget packages and deploy if it builds successfully.
I made a few changes (added a class) and checked in today. I received this error on the build:
Here's the quote to help the future search bots:
Exit code 1 returned from process: file name 'tf', arguments 'vc unshelve Gated_xxxxxx;****** /loginType:OAuth /login:.,******** /noprompt'.
I looked into the log response, to see if I get more detail, but it says the exact same thing. I have not changed my password or username.
How can I debug this to figure out the issue?
UPDATE
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
You can receive that error as well if you try to check in a file that is in a project that is not mapped in your build definition.
Let's say that you have a file named FileA.cs that is in a project named ProjectA.csproj. If you do changes in FileA.cs and this file is included in your changes, you need to map ProjectA.csproj in the Get source step of the build definition.
I have created an Azure Web Site and connected it to Visual Studio Online, and this automatically set up a continuous deployment build (as per this page).
Initially this worked for a solution with one project, but now I have added a Web API project as a back end. This is named such that it is the first of the two projects alphabetically, and so now it is the only project that gets built and deployed whenever files are checked in. Which leads to my question:
How can I modify the default continuous deployment build to deploy both applications?
I'm sure it must be a fairly simple change to either the build template or parameters, or the publish profiles that are being used by the build. The only problem is I don't know: A) how to change those settings in the default TfvcContinuousDeploymentTemplate.12.xaml build template, and B) how to modify the publish profiles that are used in the continuous deployment build.
I have already, from within Visual Studio, manually published the two projects and got them to deploy to the right locations by following the instructions in this answer. I right-clicked on each project, clicked publish, then selected the "Microsoft Azure Web Apps" publish target which (after filling in all the settings) added the publish profiles to my projects and allowed me to manually deploy them how I wanted.
Unfortunately there seems to be no way to re-upload those publish profiles so that they can be used in the CD build. I've checked them into source control, I just need to know how I can get the CD build to make use of them. How can I do this?
After reading through the first link in my question again, I noticed that you can edit the build definition (or template) to point to the publish profile that you want to use:
Path to Deployment Settings: The path to your .pubxml file for a web app, relative to the root folder of the repo. Ignored for cloud services.
Unfortunately, this both doesn't work and only allows you to specify one publish profile file. Presumably, even if specifying this argument worked, the build would still only deploy the first app in alphabetical order.
This lead me to this question and answer though, which suggests that the Azure/TFVC continuous deployment works simply by using the ordinary Web Deploy arguments to MSBuild. Looking at the diagnostic logs of my build in Visual Studio Online proved this to be the case; here are the relevant arguments:
C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe /p:DeployOnBuild=true /p:CreatePackageOnPublish=true /p:DeployIisAppPath=mysitename
So, as per that question, to use a specific publish profile you can just set the additional necessary MSBuild arguments in the build definition:
Each project needs to have a publish profile called "publishprofilename.pubxml", in this case, checked into source control. I found that the user name (which is your site name with a dollar sign in front of it) is not needed, but unfortunately the password string is required. If you don't include it you get an error like this in the build:
Web deployment task failed. (Connected to the remote computer
("[mysitename].scm.azurewebsites.net") using the Web Management Service,
but could not authorize.
No other arguments were required for me, but it doesn't seem ideal that the password has to be included. The default deployment setup, without using publish profiles, must be authorising with that password somehow, but I don't know how.
So after making this change I navigated to [mysitename].azurewebsites.net, and it appeared that still only the Web API project was being deployed. However, by going to console for the site and entering dir D:\home\site\wwwroot I can see that both projects are actually being deployed. It's just that both projects are being deployed to the root of the site, at D:\home\site\wwwroot. The DeployIisAppPath settings are different in each publish profile, but these values are being ignored. This is because the /p:DeployIisAppPath=mysitename argument to MSBuild (mentioned above) overrides any PropertyGroup settings in publish profile *.pubxml files, as described in this blog post.
What I have found is that the continuous deployment process for Azure/TFVC works by having an InitializeContinuousDeployment build activity in the TfvcContinuousDeploymentTemplate.12.xaml build template, immediately before the RunMSBuild activity. This takes the MSbuild arguments you specify in the build definition, and appends to them the ones needed to deploy to Azure. Unfortunately, this is mostly hard-coded, and that means it always specifies a single deployment path for all web projects in the solution. You can't deploy each web app to a different location using publish profiles alone.
So one workaround option is to add something like a BeforeBuild MSBuild target to each project, to override the command line value of DeployIisAppPath. The problem with this is that the path specified in the publish profile, and seen in the publish wizard, will no longer be the path actually being used for deployment.
So the solution I went with is marginally better; it is what we would describe in New Zealand as "huckery".
Basically I added an InvokeMethod build activity between the InitializeContinuousDeployment and RunMSBuild activities. The arguments for this activity are as follows:
DisplayName:
Configure build for using publish profiles (removes DeployIisAppPath MSBuild parameter)
GenericTypeArguments:
System.String
MethodName:
SetValue
TargetObject:
AdvancedBuildSettings
Parameters:
Direction: Type: Value
In String "MSBuildArguments"
In String String.Join(" ", AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty).Split(New String() {" "}, StringSplitOptions.RemoveEmptyEntries).Where(Function(s) Not s.StartsWith("/p:DeployIisAppPath=")))
What this does is removes the DeployIisAppPath argument from the MSBuild command line arguments list completely, so that it doesn't override this same property in the publish profiles. Instead of the messing around with splitting and joining the string, it would be slightly nicer if you could just append /p:DeployIisAppPath="" to the command line, but this just sets the property to an empty string and you get an error:
"ConcatFullServiceUrlWithSiteName" task was not given a value for the
required parameter "SiteAppName"
So like I said, pretty huckery, but it's a solution that allows you to have continuous deployment of multiple web projects to Azure with a minimal amount of changes to the default setup.
You can override the deployment engine in Kudu by using the Azure CLI Tools. Running the azure site deploymentscript command and passing in the parameters for one of your projects -s <solutionFile> --aspWAP <projectFilePath>.
This will create a .deployment file and a deploy.cmd (or deploy.sh if you pass the -t bash parameter) modifying the deploy.cmd to add build/deploy steps for the second project.
More information is on deployment hooks is available in the project kudu wiki.
EDIT
You can use App Setting COMMAND to add a deployment script to your site.
How do I have SSDT run my publish script when I build my solution file?
If you:
1) Right click on your solution
2) Click Configration Properties
3) Click Configuration
I can see the database project and where it is checked to deploy on build, it does not let me specify what publish script to use.
As far as I know this isn't possible out of the box.
Why? They are two very different things.
Building (if you were to think of it as code) compiles and checks, producing artefacts. For .NET code those artefacts are DLL's/.exe etc. For .sqlproj it's the .dacpac etc that turn up in /sql/[Build Configuration Name].
Publishing is akin to Deploying if you were talking .NET code. Building won't include Publishing as an action.
Ironically, a Publish action also Builds the solution, so my suggestion would instead be to consider one of the following:
Publish the project (right click Publish, or double click your chosen .publish.xml file) whenever you want to build.
Use the Post-Build command line in the project Properties to call sqlpackage.exe to deploy your newly compiled .dacpac with your specified .publish.xml profile - but note that this will also impact your use of the Publish action from within Visual Studio as a Publish builds and then publishes (so you'd end up publishing twice).
Depending on your comfort levels/if you are a command-line fan, then use the command line (bash file? Powershell?) to call msbuild followed by sqlpackage.exe. Whenever you want to build, run your command in cmd.exe.
Similar to #3, add a menu item to the Tools menu that would do exactly the same thing (msbuild followed by sqlpackage deployment) but from within Visual Studio itself.
Look at a Continuous Integration model (TFS/TeamCity/Bamboo/Jenkins and about 3000-others), which could build and deploy for you automatically with every change - either on another server, or running locally (I put this in without knowing your scenario, so may be very much unsuitable to solve your problem).
I am trying to build and Deploy our solution to Azure using TeamCity.
When I Build the azure solution (Web.Azure.ccproj) using TC, it always generates wrong file like Web.Azure.ccproj.cspkg in Release\app.publish folder. I am not understaing why it is generating a file like ccproj.cspkg. Rather it should have just generated Web.Azure.cspkg.
Note: when I try directly in command prompt (msbuild Web.Azure.ccproj /t:Publish) am able to see proper files generated.
Any reason why this is happening?
Thanks in Advance
I don't know why the generated files are different. However, if you are looking to deploy to Azure Cloud Services from TeamCity, maybe this link will help.
The linked post has a powershell script that will deploy the solution and you can include that as a build step in TeamCity. The script deals with having different Live and UAT environments etc, which you may not need.
For what it's worth, we're building the entire solution with a Visual Studio (.sln) runner and it builds the Azure projects fine.
Some of our parameters:
Targets: Rebuild
Configuration: Dev (Could be Stage or Release per our environments)
Command line parameters: /p:TargetProfile=Dev /P:Configuration=Dev
The last set of parameters are where I originally got stuck. We have profiles for Azure projects and configurations for the entire solution. We need both to get the right packages created.