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)
Related
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 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.
A little background (before I get downvoted to oblivion!)
I'm working on an intranet-hosted ASP.NET web application in a highly secure environment. At the moment it's deployed by building a package in Visual Studio, the zip file is copied onto the server and installed in IIS using WebDeploy (right-click -> Deploy -> Import Application).
What I'd like to do is deploy a sanitised version of this application to an Azure Web Site for demonstration purposes, however most of the standard Azure deployment methods do not apply to me because:
I work on a secure network so Visual Studio is blocked from connecting to Azure (rendering 95% of documentation irrelevant!)
installable software is strictly controlled on this network so I cannot install the Azure SDK needed to create Service Definitions, Configurations and Packages
The only machine I have access to which can connect to Azure is woefully underpowered and can only run puTTY, PowerShell and basic text editors.
At the moment, I have a Windows VM in Azure just running IIS and WebDeploy - this works but seems like overkill (and a good way to burn through my credit) when Web Apps in theory do everything I need.
What can I do?
Another option may be to checkin the WebDeploy package to a free subscription of Visual Studio Team Services (VSTS = TFS in the cloud) and then create a deployment pipeline in VSTS using the new Release Management features.
https://www.visualstudio.com/features/release-management-vs.aspx
in that case:
1) FTP from your machine using your own FTP client or i would recommend to use PSFTP from Putty package.
2) Still WebDeploy, but use that to generate the needed files, then you can use PowerShell like that.
You can also use https://www.microsoft.com/web/webmatrix/ to connect to azure websites. It works with HTTP, only problem could be a corporate proxy.
What are the options for deploying a web-application that is built daily using Visual Studio Online (and hosted controller) and its new build definitions to an on-premises IIS behind a firewall?
If opening up the firewall, would it be possible to add some kind of WebDeploy-build step to the Visual Studio Online build? Haven't seen any WebDeploy build steps for now though...
...or could we write a PowerShell script running daily on the IIS-server that fetches the output of the daily build from Visual Studio Online? If that's possible, how can those files be accessed?
...or could something like OctopusDeploy help out here?
would like to refrain from having to set up an on-premises build controller.
VSO Agents are lightweight and easy to setup if you have a server available. Octopus Deploy integrates nicely most on premise scenarios.
That said, if you still want to keep hosted builds, Octopus would still work.
Create a VSO build definition and include OctoPack.
Pick a hosted Nuget Server, presumably with a private repo subscription. A couple of options are MyGet and Artifactory.
In "MSBuild Arguements" include the parameters.
/p:RunOctoPack=true
/p:OctoPackPublishPackageToHttp=http://nugetrepoofyourchoice.com/nuget/packages
/p:OctoPackPublishApiKey=$(NugetAPI)
/p:OctoPackPackageVersion=$(Build.BuildNumber)
"NugetAPI" is actually a user defined variable (name of your choice) that references a Secret build variable. You will get this API Key from your Nuget Repo vendor.
On premise, in your Octopus installation, you would define your hosted Nuget feed as an external feed.
In your deployment project, it would pull the Nuget package from your hosted repo.
VSO pushes to hosted Nuget feed and Octopus pulls from the hosted Nuget feed.
Octopus deploy would work for this in a couple of ways.
1) Install a tentacle on the IIS server (either polling or listening will work depending on where you install octopus manager)
or
2) Install the main octopus deploy on a machine that has WebDeploy access to your IIS server, and use the custom library MS Deploy script
Getting the package to the main octopus deploy machine could be a bit tricky. Easiest way would be setting up a MyGet server and have the octopus server check it periodically, that way you don't need to open up firewalls to the public.
These feature are coming for VSO and were announced at Build. You will be able to deploy on-premises without needing to open a firewall port using agents.
While this is still in the works you can use Release Management for Visual Studio 2015 to pull the bits from VSO and deploy locally.
I am trying to publish the ASP.Net site in IIS to a remote machine.
Presently I am publishing the site local file system and copying that folder to remote machine using mstsc tool.
Is there any way I can directly publish to remote machine?
Sure there is,
You have to make sure web deployment service is running on your server. You can check these articles to find out how to install the web deployment. Here or here.
Once your web deployment service is running and configured you need to configure your publishing settings. In Visual Studio right click on your solution project, choose Publish and select the Web deploy or Web deploy package as your publish method setting. Good article describing web deployment scenarios can be found here.
Hope that helps you.