I work for a company that has a multi tier web site. So we have several front end sites talking to several back end web services. All this is load balanced across several servers and hosted in IIS 6.0.
When we do a new release we need to copy several sites from a staging environment onto a pre live version on the live web servers. The number and types of sites deployed in any release could vary. Currently use robocopy scripts/bat files to do this. Which works but is prone to errors and is difficult to maintain.
Does anyone have any experience of some good, preferably open source, deployment software which may aid us in this task?
I would use PowerShell and its WebAdministration module. Also have a look at Scott Hanselman's article here, where he explains the WebDeploy packaging and deployment solution (on Channel9 also).
We use a continuous integration server and Web Deploy. The only manual steps are triggering the build in the CI server.
We use TeamCity, which has a limited free version. CruiseControl.NET is an open source CI server, but the configuration isn't nearly as nice as TeamCity.
Here are a few articles on setting up TeamCity for deployment:
http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-with-teamcity-deployment-projects-amp-svn
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
Related
We have some ASP.NET web application which used in 2 ways:
enterprise solution (msi-like installer)
cloud solution (use same installer)
Currently we use home-grown installer, but consider if we can replace it with something more convenient and suitable for CI/CD development cycle.
What technologies/products can be used? Currently I think about webdeploy, but not sure how it can be applied for enterprise setup...
This is quite a broad question, but I think it deserves an answer.
1. (partially) Open source solution
One way to configure CI cycle is to use Jenkins along with MS deployment functionality. This article shows how to quickly set up a job to integrate Jenkins with msdeploy tool.
Basically it configures a job to perform the deployment using Powershell:
msdeploy.exe -allowUntrusted=true -verb:sync -source:contentpath='D:\WS\ExampleProject' -dest:contentpath=F:\webfolder,computerName=exampleproject.example.com,Username='yourdomain\username',Password='password' -skip:objectName=dirPath,absolutePath="config" -skip:objectName=filePath,absolutePath="web.config"
It also tells that the executing user should be an administrator on target server, but this can be circumvented through proper configuration of Web Deployment Handler as indicated in this article.
One intermediary step that can be done before Jenkins integration (which I recommend) is to configure Web deployment. This allows to quickly check that deployment can be performed onto target server IIS using Visual Studio and any configured user that is allowed to deploy. It also allows to quickly see the difference between current code base (web pages, JS files, binaries) and target server deployed package.
2. Visual Studio 2017 DevOps solution
Microsoft recently released VS 2017 which contains a great support for DevOps which handles most the issues related to CI/CD. I cannot find a reference, but I remember that this feature is available for Enterprise version only. Also, the good news is that it is not tightened to Microsoft technologies.
A presentation related to the subject can be found here.
I think WebDeploy can be used without significant problems. From my experience with it:
backup limitation: can be done only at Web Site level, not Web application level
deployment time: is quite small - actual files copy + Web site backup (if configured) + application pool recycle.
Recently I saw a vendor offering customers who wanted on-premises deployments the same Docker image that they use for cloud deployments. Seemed like a good, clean, solution.
Another option is nuget packages - host your own repository. Then deploy with a tool like Octopus Deploy. I'm not terribly familiar with it, but both solutions look to be easy after an initial hump in setup.
Using TFS 2010
The solution I am working with is approximately 34 projects. I have gotten my build definition to copy the build output to a separate location. of those 34 only 3 are actually web type projects. This works fine and gives me compiled code.
My issue is that once the build is deployed to that location how to configure the build definition to update the appropriate IIS website/ settings.
I looked at this location already but this seems quite error prone: http://vishaljoshi.blogspot.ca/2010/11/team-build-web-deployment-web-deploy-vs.html
I considered creating a separate .msbuild for each of my csproj files that need to be setup and have it run on Post build. My suspicion though is that this will run on the build server itself and also how would I get for example the path to even update IIS with.
Anyone have any suggestions or tips to make this moderately better?
nutshell: after deploying a different location than build server how do you automate IIS processes to pickup new build.
tyvm
MacM
You should use a deployment automation tool rather than the build tool to tackle this problem, especially if you'll be deploying to several different environments. Any deployment tool with decent IIS support will be setup to update configuration on a per-environment basis. It's the most normal IIS scenario in the world.
I think MS is including the InRelease tech in the new VS, and there are a number of other good solutions for deployment as well including Octopus Deploy, and IBM UrbanCode Deploy. .
I know its possible to develop and host an ASP.Net site on Linux using Mono and Apache, but I'd like to know how well it works and if its worth the hassle? I prefer open source, but for this project I want the quickest, easiest, most reliable solution.
The site I'll be building will be a fairly basic ASP.Net site using MySQL.
I'd like to know if anyone else has experience using Mono in a situation like mine and how the project went. How did it compare to using a Microsoft-centric solution?
I know Mono is still somewhat incomplete, but I'm hoping I won't need the features it lacks.
This question may be a bit "polarizing". Most similar questions seem to have responses from people who are either very pro-Microsoft or pro-Linux. I'm hoping for some unbiased responses, preferably from people with experience using both.
I switched from MS-centric solutions about a year and a half ago and now I'm hosting all of my websites and web projects on Linux/Mono/Apache/MySQL based virtual servers (I was originally using nginx instead of apache, but mono-fastcgi-server was randomly causing thrashing, so I choose apache as a web server). I can summarize my (subjective) experience with this configuration into a few points:
It can take some time to get used to difference between Linux and MS based environments (if you never used Linux before), but I do not regret this decision. What helped me a lot was creating installation and configuration procedures for particular technologies (for example mono parallel environments, apache virtual hosts configurations, dealing with certain issues) which are mostly repeatable and can be automated.
You can still use Visual Studio to develop your applications and then deploy them on Linux machine. If you are using this approach it's a good habit to test your apps regularly on mono for possible incompatibilities.
I deploy web applications via FTP which is probably the easiest way of doing it (well maybe WinSCP is even easier, because you don't have to set up FTP server, but it depends on your preferences).
So far I have run into 2 cases with Mono/Apache where memory leak caused unavailability of the website. This was probably caused by Boehm garbage collector which I was using on old mono installation. I haven't had similar problems with a new sgen GC on recent versions of mono.
What I like the most on mono running on Linux environment compared to MS stuff is that you don't have to click around all the time when doing administrative tasks. Shell is for me unified administrative interface which can speed up things (if you have some practice).
Hosting ASP.NET on mono from my experience is quite easy and fast. i has been host multiple of my project using Mono ASP.NET MVC 1 / 2 using MySQL and PostgreSQL, serve by Apache mod_mono.
Compared with deployment on Windows Server. It quite narrow when using modern linux distribution which already provides all package to deploy mono ASP.NET. the only drawback is you have to make sure your Web Application portable enough in term of IO accessing and only very short learning curve and experience needed to debug and publish your project.
For Deploying our project in Linux. It easy using Version Control (VS) such as Mercurial or Git if u have fully control on the server. If U have more experience using continues integration is more better. I mainly using mercurial so step bellow is the step i usually do, but i think it almost similar for Git:
Install mercurial, and configure mod_wsgi, hgweb.wsgi and hgwerb.config
Init VS repo and publish at hgweb.config and configure hook to update and invoke xbuild to automatically build when u push it
publish the repo (web part) as mono application at mod_mono.conf
So u just need to code at visual studio, commit and push your changes using tortoiseHg without event login to server (set repo url, user and password at your repo hgrc)
Please note that although you can deploy ASP on Linux via things like Mono, if you use a Microsoft ide such as Visual studio, webmatrix, or Visual web developer your licence only allows you to deploy these on Microsoft servers!
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
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.