Is there a way to specify the App Update parameter (none, minor and mayor) on deploy.msbuild?
App Update is important to deploy metadata when doing an automated deploy.
I search for these msbuild parameters with no success.
Related
I tried SonarQube and sonar-scanner for my XCUItests locally on my machine using the docker image but now I want to integrate it with our CI (Bamboo), we already have our SonarQube server but I have no clue on next steps to integrate it to Bamboo.
I am using it for UI Tests in swift using XCUITest
Click add task and choose Sonar Scanner. Update the task with values, add if sub directory required, then additional param with -Dsonar.java.binaries=target/classes, update server value for your company, update project key as unique and save with other default values. It should work.
We are using VSTS for build and release management, and using CI/CD. Typically, our solutions consist of a web application project, and a database project.
Our current release tasks take the application offline (using app_offline.htm), publish the database, then publish the web application. Publishing the database project often results in no changes, as due to CI/CD we are much more frequently updating code on the web app than changing the db schema.
Is there a way to only run the database publish task (using WinRM) when it detects a change in the database project code, in our git repository?
EDIT: This in itself isn't a problem, as typically when the DACPAC gets published, there will be no activity. HOWEVER, I've been requesting that the database is backed up using the /p:BackupDatabaseBeforeChanges=true flag - which seems to back up the database even if there are no changes. This is an issue for large databases.
The simple way is that you can separate web project and database project to two build definitions.
Create a new build definition
Enable Continuous Integration in Triggers tab
Specify Path filter to include database project
Modify Visual Studio Build task, specify /t:[database project name] argument in MSBuild Arguments box to just build database project
The same steps for web project
Create a new related definition
Add artifacts for previous two build definitions and enable Continuous deployment trigger
Add two environments (e.g. database, web)
Open Pre-deployment conditions of an environment (e.g. database)
Enable Artifact filters and select corresponding artifact (e.g. database build artifact), specify build branch (can specify *, it means all branches)
Add tasks to just deploy database in this environment
The same steps for web environment
The answer is - exactly what I want isn't possible.
During build msbuild creates deployment packages for several my web projects (and wcf services) which I want to run from command line (as last step of automated build process) to deploy to several different servers.
The structure of IIS application folders is the same on each one.
My problem is that I cannot find how to configure (override default value of IIS application). It is in .SetParameters.xml, like:
which is not what I want.
I read that it is possible to create parameters.xml in the project and put there something like:
or some say
I'm trying this but it does not change content of .SetParameters.xml
Can you advice what am I missing, or/and alternative way to do this.
Thanks!
If you want to deploy the web application package manually—either by running the .deploy.cmd file or by running MSDeploy.exe from the command line—there's nothing to stop you manually editing the SetParameters.xml file prior to the deployment. However, if you’re working on an enterprise-scale solution, you may need to deploy a web application package as part of a larger, automated build and deployment process. In this scenario, you need the Microsoft Build Engine (MSBuild) to modify the SetParameters.xml file for you. You can do this by using the MSBuild XmlPoke task.
For more information, please refer to: https://www.asp.net/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment
I have set up a build step on TeamCity,as described here, to do automatic release deployments to our test server. But it is not using the latest nuget packages that was build in TeamCity.
Use Case :
Teamcity will create nuget package with version 1.0.0.9, all the dlls that is in the package is the correct version, and the Release in Octopus, that was deployed has got the same version number , but the packages that octopus uses is of an earlier package eg 1.0.0.5.
I have specified the --force parameter on the build step so it should use the latest packages but it is not.
If I manually create a release in Octopus, and select the latest packages it is working 100%
Please can someone tell me if I am missing something.
thanks in advance
I think what you need to do is create two build configurations in TeamCity, one to build and one to deploy with Octopus. Refer to this link that has a small blurb toward the end:
Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes.
So in my case I created 2 build configurations, then setup a snapshot dependency from the build to the deploy config and also a trigger to kick off the deploy after a successful build.
It looks like --force is just to force packages to the be re-installed if they have already been installed. Are you using the --packageversion parameter?
My organization uses Jenkins CI. We use the unique build number as our package version and then deploy that specific package version using the --packageversion paramater.
In the case where we have multiple services that need to be deployed. We have an upstream job / main job that provides the unique build number.
I'd imagine you can do the same thing with TeamCity
Master Job (unique build number) calls jobs A and jobs B with parameter (unique build). Jobs A and B build version (from Master Job). Jobs A and B complete then publish their respective versions.
It could be a few things.
Check out.
http://octopusdeploy.com/documentation/integration/teamcity
You haven't mentioned how your consuming the feeds from Octopus in Teamcity. I would start there.
Next I would use the teamcity action to do your deploy. You asked "Where should the --waitfordeployment flag be added" there is a check box to make sure the deploy has worked before the action can continue.
In TeamCity I use a Octo Push Packages step and in the Additional Parameters field I specify the --defaultpackgeversion {VERSION} parameter.
This will force Octo to use a specific version of packages instead of just choosing the 'Latest Version'.
There are more possible reasons for the problem.
To see the problems with Octopus go to Configuration -> Diagnostics
Another common problem is to use a Package Name #{variable} in a deploy step
Currently it is not possible and Package Name should be set manually, for example MyWebSite or MyWindowsService. See UserVoice for this feature.
This is almost a duplicate of Link build configuration to a publish profile, but that question was not answered...
I have 2 1 Click Publish configurations for my Web Application:
Test Server
Production Server
If I select Build => Configuration Manager => Release and then click the Publish button my application will be published with a release configuration (and visa versa) - without regard to the current Publish profile selected.
But what I REALLY want is...
To set the appropriate Build Configuration from the 1 Click Publish settings. Test Server should be published with my Debug settings and Production Server should be published with the Release settings.
I shouldn't have to make the change from within the Configuration Manager. But I Do.
So, I have 2 questions:
Am I just doing it wrong? Based on a little note in the Publish Settings stating "Use Build Configuration Manager to change configuration" this seems like this is exactly how it is intended to work.
Is there another way of having 2 publish profiles, one with a Debug config and one with a Release config?
The only thing I'm using the debug/release build configurations for is for my Config Transforms that have different connection strings. So, alternative, but still 1 Click, publishing solutions are acceptable. :-)
It's possible to do another way by having multiple Web Deployment Packages.
Basically create two different projects and each one will compile and set the asp.net build config and output. Then script the deployment as part of it.
Bit hacky (wish the publish profiles could set the build config as you wished).
Other than that I normally do via powershell scripts and kick off from my desktop deploy that does all the appropriate compiling and deployment scenarios.
http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
http://johnnycoder.com/blog/2010/01/07/deploy-aspnet-web-applications-with-web-deployment-projects/
I was able to get this to work by installing the Visual Studio Web Publish Update. This update allows you to tie a build configuration to a specific publish profile.
http://msdn.microsoft.com/en-us/library/jj161045.aspx