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.
Related
I'm trying to setup CI via TFS 2015, I've got a solution that has got 2 main Web application that currently we deploy manually editing the config files and so on (which sometimes leads to errors)
I've read about build/release process and in the past I've used Jenkins as build server. But till today I've got a question and that's related to when apply the transformation of XML config files.
In my current VTFS2015 setup I've created a build process and I build the project with the following line
msbuild /p:Configuration=Test /p:PublishProfile=Test /p:DeployOnBuild=true xxx\xxx.csproj
This creates me in the folder obj\Test\Package\PackageTmp the package
Is this ok? or should this be done in the release management tab? Consider in my farm I've
Test (from DEV trunk)
Staging (from Dev trunk as well)
Production (from production trunk on 3 machines)
My goal is to have them automatically delivered on the machines, but I don't know the right moment to apply the transformation (during the build I can use the publish feature, during the RM I can use a ps1 script)
Thanks in advance
Well, I think this thread will helps: What TFS 2017 build task applies web.config transforms during TFS builds?
To apply the transformations you can use the extension: Apply transformations in vNext build process.
Usually it should be a package and be used in a deploy task such as
Deploy: WinRM - IIS Web App Deployment or Azure App Service
Deployment to achieved the deployment.
1) Can transforms be engaged in both Builds and Releases?
Yes, you could also do this in a build pipeline with the useage of build deploy task. You need to add the task after the publish build
artifacts task.
2) Does TFS 2017 require a lot of special handling to engage a
transform file?
update
The BuildConfiguration variable is different in TFS 2017, it's inside
the MSBuild task! Transforms are now applied according
to the MSBuild task Configuration setting.
Edit the .proj file is a method to do the transform. If you don't need to change the transform, it will auto do it during the build.You
could also use some 3-rd party task/extension for extra transform such
as: XDT Transform
Usually we separate the build and release for the deployment, cause
it's easy to configure multiple environments and easy to debug issue.
You definitely could do this only in build but with a bloated process.
You could refer this tutorial: Build and Deploy Azure Web Apps using
Team Foundation Server/Services vNext Builds.
For a separate build and release solution, you could take a look at
this blog: Using web.config transforms and Release Manager – TFS
2017/Team Services edition
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.
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.
I am currently integrating in web deploy package publish via visual studio and tfs bulid 2010 and have some questions:
For different environments, is a Publish profile needed for each?
As part of the publish is it possible to execute a generated database against a database?
Within the publish profile is it possible to create an application pool, web site, configure it etc if it doesn't previously exist?
Re tfs build - is it possible to click a button to deploy a successful build based on a selected publish profile?
Thanks for any feedback!
I know you're trying to use webdeploy, although most enterprise architecture will use other tooling. I suggest using powershell remoting tools. This gives you the full power of the .NET framework to do database deployments using whatever tools you want.
I usually create different transforms to transform the configuration files. Depending on what environment you deploy to you can use the appropriate transform that matches your environment or manipulate the transform as desired.
We have several web services that we have been deploying "manually" using msdeploy. We pick up the deployment packages from the TFS2010 build machine in the appropriate _PublishedWebsites\<<ProjectName>>_Package directory.
We now want to wrap the deployment packages up with a deployment tool that makes it easier for the person doing the installation to see the parameters.
What we'd like to do is to build the individual web service deployment packages, have the deployment packages land in the right place for the deployment tool build and then have the deployment tool build both build the tool and copy the previously-built deployment packages to the same Binaries drop folder on the build machine.
For some reason, this seems incredibly difficult to do.
Things we've tried
Setting Location where package will be created on the web services project's Package/Publish Web project settings using a variable (e.g. $(TargetDir)). Visual Studio interprets the entered variable and replaces it with the hard-coded path for the development machine... and that's what goes to the build machine. On the build machine the end result is... nothing; the deployment packages are still sent to _PublishedWebsites\<<ProjectName>>_Package.
Setting /p:PackageLocation on as one of the MSBuild Arguments settings on the TFS build definition "Process" / "Advances" section, in addition to /p:CreatePackageOnPublish=true /p:DeployOnBuild=true. All this did was generate the error:
MSB1008: Only one project can be specified. Switch: p:PackageLocation=$(BinariesRoot)\DeploymentFiles For switch syntax, type "MSBuild /help"
presumably because there is more than one deployment package being generated by the build.
Any advice appreciated! Are we going about this the wrong way? Should we be doing something like altering the build XAML to cater for this (like this page suggests for another issue)?
Couple possibilities for you to consider:
1 - Alter the TFS workflow like you've described to perform some copy task
2 - Create an MSBuild project that runs after your standard Packaging steps to copy the output from _PublishedWebsites to some location of your choice
3 - Override the following MSBuild parameter when building the package to change the package drop location:
<DefaultPackageOutputDir Condition="'$(DefaultPackageOutputDir)'==''">$(OutDir)[YourDesiredLocation]\$(DefaultMSDeployDestinationApplicationName)\Package</DefaultPackageOutputDir>
Note that you can see the set of packaging MSBuild parameters available to you at
c:\program files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I recently implemented suggestion #2 at a client, using the MSBuild overrides suggested in #3 in the custom MSBuild project file and it worked like a charm.