I have a build pipeline and a release pipeline. The solution I'm building contains a web project and a class library project containing selenium tests.
Currently, the web project is copied to the artifact staging location and then published. The release pipeline takes care of publishing the web application to the hosting location.
I would like to run the tests in the class library but without publishing the project build to the hosting location.
This page appears to indicate that the build should produce the output of both the web project and the test project:
https://learn.microsoft.com/en-us/vsts/build-release/test/getting-started-with-continuous-testing?view=vsts
As I don't want to publish the test project, how should I configure a build to provide me with both sets of binaries while hosting only one?
Publish two sets of artifacts with your build: One containing the application, one containing the tests.
You can then deploy the application normally and skip deploying the tests, then run the tests at the point in your pipeline that it makes sense.
There are many ways to get test project/assembly, but publish the files to artifact is better and simple.
Add additional artifact with Git/GitHub/TFVC … source type (where the
test project source in) to release definition, then build the test
project and run test
Add additional task(s) to download the test project/assembly, such as
windows machine copy, FTP download … or you can do it programming
(e.g. PowerShell)
Related
I have a standard way of working for building and deploying my asp .net applications on a build server (usually Jenkins). I have a custom build script and publish profile that builds my solution, copies some files and publishes the web project all with a single call to MSBuild.
I am trying to recreate this in Azure DevOps. My first obstacle seems to be that build and "publish" (or "release" in DevOps parlance) are separate steps. But it also seems like maybe I don't need to "publish"?
So
How do I control what ends up in the "artifacts" folder of the build? Is that through Azure? Can I do it with a .MSBuild file? And
Do I even need the concept of "publish" or does the release step just copy all artifacts to the destination (a VM in this case)? Can I control what gets deployed?
I am having a hard time finding some kind of basic tutorial that cover asp .net projects being deployed this way.
How do I control what ends up in the "artifacts" folder of the build? Is that through Azure? Can I do it with a .MSBuild file?
Yes, we could use the MSBuild Arguments parameter /p:PackageLocation=$(build.artifactstagingdirectory) to control what ends up in the "artifacts" folder.
When we use the task Visual Studio build to build the project, we could edit the MSBuild Arguments parameter to be like: /p:DeployOnBuild=true /p:PublishProfile=Test /p:PackageLocation=$(build.artifactstagingdirectory)
Then we could use Publish Build Artifacts task to publish build artifacts to Azure Pipelines, TFS, or a file share.
Do I even need the concept of "publish" or does the release step just copy all artifacts to the destination (a VM in this case)? Can I control what gets deployed?
Yes, you can simply understand the release step just copy artifacts to the destination. If you want to control what gets deployed, you can filter the artifacts when you use the copy task with contents.
Check the article Deploying Web Applications Using Team Build and Release Management for the details.
Hope this helps.
If you have existing scripts that work, just use those :). The new YAML builds are moving slowly away from fully featured UI tasks with lots of logic to more bare bones scripts that do what is needed.
It is a common practice though to split build from publish. That way you can put in additional checks, reviews and approvers on the release stage.
In your case it would mean:
Build stage
Use MsBuild to build & create a publish package either in the form of a folder or a zip file.
Use the Publish Pipeline Artifact task to store this folder or zip file
Release stage
Use the Download Pipeline Artifact task to restore the file to publish
Optionally use a Infra as Code tool to prep the target environment.
Use msdeploy.exe or another tool to publish the package. Optionally generate and pass in a settings file to override certain settings.
This way you can have multiple release stages to generate test environments, temporary POC environments etc by simply using another set of variables and/or settings override file.
There are special tasks in Azure Pipelines that wrap around these tools and provide an easy to use UI and some additional logic. These can be very useful if you don't have intimate knowledge of the commandline tools. If you do know your way around them, there may not be a very strong reason to use the fancy tasks.
I have done a fair amount of research for publishing and deploying web apps with VSTS and so far I have found the following:
1.Use .pubxml files and pass the DeployOnBuild = True to MSBuildArguments
2.Copy and publish Artifacts and create a separate release definition.
We are currently using the first method, but found that the build can be marked as successful but the publish fails (in our case it was a bad transform)
So we decided to look into separating the publish step and to create a release for our changes.
The issue I am running into is that the copy files and publish artifacts step only copies DLLs and our .js and .html/.css changes don't seem to make it to the UI. As a work around I added these params to the Copy Files method but it is taking a long time to publish. (There are no issues with the release definition)
**\*
!$tf\**
**\!$tf\**
**\!Debug\**
**\*!pdb
All the guides online for using the Publish Artifacts and creating a separate release definition seem to say the same thing, and only push Dlls from the bin folder to the IIS server.
Here is my build definition:
So my question is, why aren't UI changes being deployed to the website when the release completes if this isnt an issue anywhere else?
No, not really. We usually not only publish DLLs and our .js and .html/.css as build artifacts, but for the whole web app.
The Visual Studio Build task usually with the MSBuild Arguments as (if you use ASP.NET build template, it's the default setting):
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
In this way, the web app (published files) will be copyed to $(build.artifactstagingdirectory) directly. So you don’t need the Copy Files task.
If you need to deploy all files, you can use ** in Copy Files task.
Then when you deploy the app to IIS server in release definition, the whole web app in build artifacts will be downloaded.
I am currently using Visual Studio Team Services (was VS Online) to version control my projects. When I want to deploy my projects to my VPS I use the Visual Studio Publish that stores the files on my hard drive and then I use an FTP client to send the files to my VPS.
But now I am viewing the build and release functions in Visual Studio Team Services. But I don't completely understand it all.
Questions:
What is the purpose of the build?
I have created a new standard build definition using the Visual Studio template and used the Host agent pool.
When I run the build I can see that it creates a new version using the last commit as reference. But what has it done in the backend on the host agent?
And where are the files stored of this new created build? In the log I see Copy Files to: $(build.artifactstagingdirectory) but where is this?
What is the purpose of the release?
I have created a new release plan using the empty template because I don't have Azure, I use another company where I have a VPS running.
I then added 3 environments called Development, Staging and Production.
All of them using the Host agent, but I think here I need to adjust this because if I understand it I now can assign my VPS to my Production environment or not?
Does someone has done this using Visual Studio Team Services and a VPS that runs on Windows Server 2012?
Are there videos or docs available about this because its quite confusing what the correct steps are in deploying versions of web projects.
In general, "Build" focus on integrating and building your code changes and run some basic unit tests. And "Release" is used to deploy the output of "Build" to your environments so that you can run some future tests/verification and final deploy the output to a production environment for your customers to use. See this link for reference: What is the difference between build and release engineering, DevOps and site reliability engineering?
When you start a build without any source version specified, it will get the latest version of the code and then build the code. All the files are placed in the working folder of the build agent during the build process. $(build.artifactstagingdirectory) is a predefined variable that point to a path in the build agent work folder. We usually copy the build output to this path so that we can access to output easily in the following tasks. For example, use "Publish Artifact" task to publish the output files in $(build.artifactstagingdirectory) folder to the server or a file share, and then the team members can get this build from server or file share.
In the release, you can link a release to the build definition. When the release starts, it will get the latest artifacts of the build and deploy to your environment.
The agent is a machine used to execute the tasks in build/release definition. Hosted agent is managed by Azure and you can also deploy your own build agent. So you don't need to change the agent settings for "Production" environment if your VPS can be accessed by the Hosted agent. Since you are using FTP to upload files to your VPS previously, you can still use this method to publish the files by adding a FTP Uploader task in release definition.
For more information, refer to Build and Release Management for details.
We are currently using Team Foundation Server Build Definitions to build our solution and now I want to add deployment to that. We are using TFS Build servers out of the box for our builds. Currently, we are deploying the web app to our dev integration servers using Web Deploy (MSDeploy) from within VS2010 (Publish on the toolbar). The desire is to move this publish to the build server.
What is the best approach to be able to reuse the MSDeploy mechanism (since it's already in place on IIS) and have the build server take over that task? Can I use MSBuild params or do I need an MSBuild project file? How would I configure the appropriate approach in the Build Definition? It is unclear how to configure a Publish using a Build Definition and MSDeploy.
P.S. I've seen several mentions of MSBuild using MSDeploy with cmd line params, but not in the context of using a Team Explorer Build Definition.
Some links to pages that I've seen, but are incomplete based on my needs:
Creating a Build Definition That Supports Deployment
How to Publish Web with msbuild?
The ALM Rangers' Building Guidance has all the information you are looking for, in particular the chapter "Deployment of Applications and Data Stores".
Does Microsoft offer a tool where you can deploy a web application to multiple web servers in a load-balanced environment/web farm?
My team is looking for a tool, preferably from Microsoft, where we can deploy our web application from development environment to production environment automatically.
If I understanding what your asking for your looking for a build server, to my knowledge Microsoft don't offer one, but some to take a look at are Team City, Hudson(requires a plug-in), and CruiseControl.net.
Basically they work by pulling from your source control building your application and running your tests. They all support scripting that will allow you to build then deploy to your servers. This can be set up to run nightly, weekly, etc. you can also set it up to monitor your source control for changes and build anytime it sees a change
The only one I've used is Team City, the install was easy, and depending on how many build agents you need it's free.
If your just looking to build and deploy from VS Another option is creating an NAnt script and running it from VS as an external tool.
For a good over view of Build servers check out this SOF question cruisecontrol.net vs teamcity for continuous integration
The Web Deployment Team blog at Microsoft has some reasonably useful information, and have a deployment tool you could try...
In the last environment we setup we used TeamCity for all our builds and deployments (Which is basically to say we wrote MSBuild scripts and automated them with TeamCity). In short we had the following 5 build configurations:
Continuous Build - Automatically rebuilt our product upon every check-in. Running all the tests. This build did not deploy anywhere
Nightly Build (Dev) - Automatically build and deployed our product to the development web server (no server farm). We build would run the tests, update the development database, shutdown the Dev IIS web site, copy the necessary files to our web server, and restart the site
Test Build - Like our Nightly build only it deployed to our test environment and it wasn't scheduled so it had to be manually started by logging into Team City and pressing a button
Stage Build - Like test only deployed to a web server that was externally visible to our customers sot that they could validate the application. Also, only run on demand.
Production - Created a zip file of our product that the deployment team could install on our production web servers
So I guess what I'm suggesting is that you use TeamCity and then write build scripts in such a way that they'll deploy to your Web Farm. If you want examples I could supply you with the pertinent portions of our build scripts
** One more thing: we check in our web.config files and such for each environment into subversion and then part of the build process is to copy and rename the appropriate config file for the environment. For example, web.prod.config => web.config in our production build
I believe that Sharepoint does this.
File Replication Service ( e.g. DFS Replication ) is a typical and very good choice for doing this.
Your changes are synced between member servers at the file system level.
Sharepoint does this automatically when you deploy a solution package.