Here is my situation. I have a ASP.Net web forms application with code hosted in Visual Studio Online using TFVC. I recently started using CI tools in VS Online to automate everything from building, unit testing, integration testing and production deployment.
I started in baby steps. The build is working, it runs unit tests. But when it comes to unit testing using IIS, it throws below error inside the CI console.
[error] The test or test run is configured to run in ASP.NET in IIS,
but the current user (TASKAGENT-0005\buildguest) is not in the
Administrators group. Running tests in ASP.NET in IIS requires the
user to be in the Administrators group.
I could see that its clearly telling about admin privileges. Googling is not giving any suggestions. Any idea how to give permission? Also is VSOnline supports testing by hosting ASP.Net temporarily in build machine. Below is the unit test method which I use to test by hosting inside IIS.
[TestMethod]
[HostType("ASP.NET")]
[UrlToTest(Common.BaseUrl + "Blogs.aspx")]
public void WhenChangeLogPageIsRequested_TitleShouldBeProper()
{//Code goes here
}
A typical continuous integration and Continuous Delivery workflow will contain:
1.Create a new Agent Pool, install Build Agent and configure permissions
2.Create a new build definition and configure it to execute Unit Tests (Continuous Integration)
3.Package our the built website as a Web Deploy Package
4.Create a Machine Group and add a new test web server
5.Use PowerShell DSC to configure a basic web server (IIS, ASP.NET 4.5, Website & WebDeploy)
6.Use WebDeploy to deploy the site package to the newly configured Web Server
7.Auto deploy and configure the new Test Agent on our web server
8.Run Coded UI Tests and report results
Follow the video at website: http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/17/video-configuring-continuous-integration-and-continuous-testing-with-visual-studio-2015.aspx
Related
We currently use Octopus Deploy to push web sites to IIS servers hosted on Window Server 2012.
We wish to ditch Octopus and use our on-premises TFS 2017's inbuilt release system instead. We have build definitions that publish artifacts (the web site binaries & content) ready made .
With Octopus we have tentacles installed on all the servers.
The legacy release process defined in Octopus is like so:
Set up IIS (Powershell script to configure app pools for a site, map virtual directory to absolute path)
Deploy nuget package (package contains web site binaries & scripts) - unpacks package containing web site to the physical path of the associated virtual directory
Enable Windows Authentication (one-line powershell script that calls Set-WebConfigurationProperty)
Disable Anon Auth (powershell again.)
I'm not keen on the amount of Powershell used in our Octopus process, and would like to minimise Powershell in the TFS release definition.
My question is: what is the Microsoft recommended way of deploying ASP.NET web sites (vanilla MVC projects, not .NET core) to servers in a CI environment? Is it possible to configure the sites authentication at the same time?
NB:
I took a look at the OOB IIS publishing WinRM deployment tasks and I fear they may require more time than our infrastructure team has (to configure firewalls etc.)
We have Visual Studio 2017 installed on the build server.
TIA,
Scott
According to your description you are deploying on a Web site hosted on IIS.
First through TFS build you could use some msbuild arguments such as /p:DeployOnBuild=True /p:SkipInvalidConfigurations=true /p:WebPublishMethod=Package /p:PackageLocation=$(Build.ArtifactStagingDirectory) /p:PackageAsSingleFile=true to generate a package.
Then in release definition use Deploy: Windows Machine File Copy task - Copy the Web Deploy package to the IIS servers. Finally use Deploy: WinRM - IIS Web App Deployment - Deploy the package. This task running on the Build and Release agent opens a WinRM connection to each IIS server to run Powershell scripts remotely in order to deploy the Web Deploy package.
For more detail/step to step tutorial, you could reference below tutorials, even some are the samples for web app:
End to End Walkthrough: Deploying Web Applications Using Team Build
and Release Management
An ASP.NET MVC Site That’s Easy to Deploy from a TFS Build
Working with Web Deploy and Release Management
Using the IIS WinRM tasks would probably the best and easiest way to do it. You can find some good guidance of how to configure things.
The basics that you need in place are:
Make sure that WinRM is configured on the target server and that your agent can connect to them
Package your web site by adding these msbuild parameters when you compile the project
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(Build.ArtifactStagingDirectory)
Background: I am doing a POC for CI using Jenkins and MSBuild. I have installed Jenkins, MSBuild plugin and other required components on my machine and configured as well. But I don't have IIS configured on my development machine.
I want build the ASP.NET website and output the published code in a folder "c:\precompiledweb" using MSBuild script. I have
Can someone help me with MSBUild Script.
Make sure you read the prerequisites for functionality.
https://msdn.microsoft.com/en-us/library/1y1404zt.aspx
Walkthrough: Deploying a Web Site Project by Using the Publish Web Site Tool
Prerequisites
In order to complete this walkthrough, you will need the following:
Visual Studio.
*This walkthrough assumes that you selected the Web Development collection of settings when you started Visual Studio the first time. For more information, see How to: Select Web Development Environment Settings.
Access to Microsoft Internet Information Services (IIS) so that you can test the result of publishing a Web site project. In this walkthrough, it is assumed that you have IIS running on your own computer. Alternatively, you can use any instance of IIS for which you have permission to create a virtual directory.*
You need access to some IIS server.
On the flip side....you need to keep this general rule in mind. Jenkins is simply a fancy wrapper for command line calls.
So test the below (article) on your machine without IIS. If you can get the command line to work (outside of jenkins), most likely you can get it working (inside jenkins)
http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/command-line-deployment
Configure Source Code Management section, i.e. for TFS:
Add build step "Execute Windows batch command"
Insert msbuild invocation to your solution, i.e.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
"%WORKSPACE%\{solution_name}.sln"
You can add some optional parameters.
After build you can add another script invocation (batch, powershell, whatever) for copy project output to specific folder, but I would prefer another way: publish to IIS and run application immediately.
in Visual Studio create publish profile with WebDeploy target (help)
enable Web Deploy in IIS on test machine (help - when componentes are already installed go to "USING THE IIS MANAGER TO CONFIGURE WEB DEPLOY FOR A NON-ADMINISTRATOR" section)
add publish parameters to jenkins job from step 2, i.e.:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
"%WORKSPACE%\ {solution_name}.sln"
/P:DeployOnBuild=true
/p:PublishProfile="{publish_profile_filename}.pubxml"
/p:Configuration=Release
/p:Platform="Any CPU"
/p:Password={Password_for_publish_profile_same_as_used_in_VS}
And now you have jenkins click-once job for build and publish solution to test server. Add Source Code change trigger and you have basic CI.
I have seen this asked here before, but none of the other posts solved my issue, so here goes nothing.
We are attempting to use Web Deploy on IIS to automatically deploy our application to a test environment. The idea, besides bettering our deployment process, is to allow Jenkins to deploy our application to IIS and run a few automated tests.
For this we are attempting to use MSBuild along with a deployment profile on our web app. The IIS lies on a Win8 virtual machine, where we try to run MSBuild and it fails because the Web Management Service is not up, and it doesn't show anywhere on the IIS management software.
I have the Web Deploy feature installed, as I have seen from Web Platform Installer, but the Web Management Service icon is nowhere to be found. I have found and started the service manually on the Windows Services configuration, but that doesn't seem to have helped either.
A few other observations:
"IIS: Management Services" item doesn't seem to show up on my Web Platform Installer;
I tried changing my installation (under Windows' Add an remove programs) to include web management, id didn't help
I enabled IIS' Web Management on Windows' "Add and remove features" settings. Also nothing shows up on my manager.
My Windows language is set to Portuguese. I may have missed the config due to bad translation, but that's unlikely.
So, how do I get the service to run so I can configure it on my IIS and finally deploy my application?
Client OSs doesn't come with Web Management Service. You cannot set up remote publishing using Web Deploy for a site that is hosted in IIS on Windows 8.0 or 8.1. You need server OS for same.
Is there a way I can deploy my entire website/webapp to an Azure WebRole without the need of Visual Studio?
Context: We have a test environment where there's an IIS hosted web app where our testers test (of course). The thing is, we want to grab that exact tested web app folder and deploy it "as is" to a WebRole.
Please avoid commenting on our procedure, we have been looking at it and we will eventually change it if we have to, I just need a 'simple' yes(how)/no answer.
IIS Web Deploy can be used to package/migrate/restore IIS applications. It can be enabled while deploying a web role as described in this article and allows to update the web role with the application as deployed in your test environment.
Be aware that only single instance cloud services are supported and that in case of a maintenance operation by the fabric controller, your service will be rolled back to the state created by the initial azure package deployment. (There once was a tool for syncing between multi-instance web deployments but sadly that did not work out too well and is no longer supported. Do not attempt to use or rebuild it.)
Installing and Configuring Web Deploy shows the steps to get web deploy for your local testing IIS while articles on using web deploy like this one show examples for calling the tool.
Another option to evaluate are azure websites and git deployment. This could provide you with a documented and reproducible form of deployment that is not prone to unwanted rollbacks while allowing the service to scale to multiple instances. This option might not work out if the application it too tied to the web roles infrastructure or contains code not suitable for the more restricted web sites environment.
A third option to look at is using CSPack as presented in this article. You basically create a service definition and package up the webapp manually without building it in Visual Studio or TFS.
Yes - make sure you have enabled Remote Access on your webrole. Then copy your web app from your local IIS folder to F:\sitesroot\0 (NOTE - may be E:\sitesroot\0 on same web roles).
Yes, you can write a programmatic interface against Web Deploy from your C# code. If you're deploying to Azure Web Sites, you could also use the Windows Azure Management Libraries to spin up new web sites or clouand deploy them.
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.