After a number of failed deployment attempts (configs overwritten, files missing, out dated etc) to our shared hosting server I thought I might get some insight on processes to make deployment run more smoothly.
We use SQL Compare to move database related stuff over and that seems to work well.
The web site itself is in SVN source control, to deploy we create a tag for the current release and then export the files. We then upload the exported files to the server through ftp manually making sure we are not overriding server specific files.
Is there any (free) tools that can assist in this or do you have a solid process that you generally follow?
For the web stuff, I'd recommend you look at the asp.net web deployment project add-on for Visual Studio. Using the web deployment project, you can take advantage of various degrees of pre-compilation and handle all that messy config file search-replace stuff too. Doesn't work with Web Dev Express though...
For the database end, SQL Compare is a good way to go, so if that is working fine for you stick with it.
Related
I'm basically wondering what the best way to deploy an Asp.Net Web Site is, mostly from the point of view of security. Right now, I'm trying to publish the website using Visual Studio 2010. Could someone direct me to a good tutorial on how to do this securely? For example, can it be done over an encrypted connection via Visual Studio? Is it necessary to install any software on the server to do this? Should I use a different program to open up an SSL (TLS) connection first, and if so, which program (does it come standard with windows)?
The server is running Windows Server 2008. Development is on Vista.
Many thanks in advance for any direction in this matter!
Andrew
I would publish the site to your local machine and file copy the files across to your test/production environment. As a rule we don't publish sites straight from VS to test or production.
For example you don't want to accidentally push things straight from dev into a live environment do you?
As far as the file transfer security goes you could use SFTP.
Note: First thing is to check with the owner of the server, as they often will provide you an FTP connection and will take care of configuring IIS.
If you want to add security, make a keyfile and sign your assemblies and consider running Dotfuscator on your dlls, the community edition is included in Visual Studio. Here is an earlier question where I've put more info on Dotfuscator.
If you have to do the deployment yourself, here's a few things to consider.
XCopy (easy)
MSI (have to create a setup program, you can do this easily in Visual Studio)
There is no security advantage in deploying using Visual Studio, but you can use Visual Studio to create a small setup program. One thing you want to make sure for security is DO NOT deploy any .cs files. Prepare your files, you should compile in Release mode, make sure debug is not enabled in your config file, keep your bin and it's dll, also the aspx, asmx, ascx, svc, css, js, and config files.
XCopy: Install a small FTP server, or use one your company alreayd has, this will allow you to get your files once you are logged into the target machine. You should be able to get an administrator account for the target machine, just ask the sysadmin of the domain, then log on using remote desktop, got to your ftp site, and download your files. Open IIS on the target machine, create a virtual directory and a pool. Copy your files to the location, configure your connection string to your DB if you use one, then test your website.
MSI: same process as above, except the setup will create the virtual directory and pool for you.
Here is extra info on best practices from the official ASP.Net website.
If you have some control on the server (e.g. to configure IIS7), you might want to look into Microsoft Web Deploy (new product just been released):
http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Haven't tried it myself, but looks quite slick and it apparently encrypts the data being copied up, so might suit you.
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.
I want to update an ASP .NET web application (including web.config file changes and database scripts) to multiple production environments - ideally with the click of a button. I do not have direct network connectivity to any of them. I think this means the application servers will have to "pull" the information required for updating the application, and run a script to update the application that resides on the server.
Basically, I need a way to "publish" an update, and the servers see that update and automatically download and run it.
I've thought about possibly setting up an SFTP server for publishing updates, and developing a custom tool which is installed on production environments which looks at the SFTP server every day and downloads application files if they are available. That would at least get the required files onto the servers, and I could use xcopy/robocopy and Migrator.NET to deploy the updates. Still not sure about config file changes, but that at least gets me somewhere.
Is there any good solution for this scenario? Are there any tools that do this for you?
I think the pull rather than push strategy somewhat flaunts conventional wisdom... but this seems like something CruiseControl.NET could easily do. Remember the web.config file is also an XML document, so is easily modifiable in a CruiseControl script. You could xcopy files or use an svn export.
http://varunkumargoel.blogspot.com/2010/03/how-to-make-automatic-deployment-for.html
Please view the above mentioned blog there i have posted details regarding automatic deployment of .NET application with SVN.
I've been doing PHP/MySQL websites with shared hosting providers for the last couple years. The day-to-day process is basically:
develop in Eclipse, one website per folder
upload via FileZilla, one website per folder
use PHPMyAdmin to create and manage your local and online databases and transfer data from one to another
to backup the online database I do dump of the database tables into script and copy them locally
I now want to build websites with ASP.NET with SQL Server 2008 on shared hosting providers, and am trying to get into this new paradigm, hopefully some of you can give me some pointers based on your experience and tell me what I am not doing optimally:
I've installed both the Visual Web Developer 2008 Express as well as the full version of Visual Studio 2008, both seem to be full-featured tools for developing ASP.NET sites. In terms of websites at shared hosting providers, what can you do with the full version that you can't do with the express version?
I use FileZilla to upload my sites, which seems to work fine. Do you use an external FTP program to upload your sites or do you use the "Publish" or "FTP Website" in the above IDEs?
I installed SQL Server 2008 Management Studio and can now issue SQL commands to my online SQL Server database (although I strangely can't see my database in the list on the left, I can still access it, I assume this is some rights issue with my provider, www.domainbox.de, but this provider told me to use their online manager instead, which is called "ASP.NET Enterprise Manager" which is extremely simple but at least has a "Query Box" which allows me to send queries to my database.) Is this "ASP.NET Enterprise Manager" standard with ASP.NET hosters or is there something else that is better, e.g. where you could edit your data in the grid, etc.? And I assume that with most providers you are able to manage your online SQL Server database with SQL Server Management Studio, is that correct? (I remember back in 2001 managing online SQL Server 2000 database at a shared hosting provider with Enterprise Manager and it would take literally 10 minutes for me to see my database on the left because it listed out the other 800 customer databases as well -- hopefully this has been solved by now).
How do you backup your data in your online database to local storage? (currently I would have to write code that output my data to some other format, e.g. XML or SQL Script)
And after you make a number of structural and data changes to your local database, how do you transfer those changes and the new data to your online database? (I had to install SSMS Tools [http://www.ssmstoolspack.com] to be able to dump my data into a script so that I could get it back into my online database).
So, although I've gotten most things to work, I feel like there must be better ways to go about this, better providers, better tools, etc. Would like to hear some "best practices" advice from anyone who works with ASP.NET, SQL Server and shared hosting.
For the most part, what you're doing now will work with an asp.net website.
For your development environment, I don't think you will be limited by using Visual Web Developer 2008 express for what you want to do. Here is a microsoft page that compares every version of visual studio 2008, including Visual Web Developer 2008 Express: Visual Studio 2008 Product Comparison
For deploying your website over the net, I would generall stick to deploying manually. You can use some of the automated stuff in visual studio, but your deployment will tend to be a little slower. After compiling your application, it will then delete every file in your destination website, and upload everying from scratch (uncompressed I think). Your whole site will be down while this happens. When you deploy manually you can upload just the changed files, or everything in a compressed format.
Regarding the SQL server, many shared hosting services will let you connect with some sort of local SQL management tool. However, connecting this way generally uses a lot of bandwidth so they throttle the allowed bandwidth for this way down. This is probably the performance issues you previously saw. If you can get by with it, I would use their hosted SQL tools for most of your work, but then use the management studio for anything it can't handle.
For backing up your SQL server, if your host doesn't have a way for you to perform an automatic backup then you will have to do something yourself. I would first check to see if they will allow you to at least run a SQL backup command. This will generate a .bak file of your database, but on the local database server. Most places will work with you on this, since many customers need this.
For applying changes to your database, your best bet is to script all of the changes into one sql script and run it using the remote SQL management tool. These aren't hard to write, and there are a few tools out there that will help you with it. I personally like to use Visio. It lets me compare two databases (local and remote) then generate a script to apply to the remote one with all the changes.
Good luck
As far as capabilities of VS Express vs Standard - Standard is still the better tool. It gives you a richer debugging experience, broader support for solutions/projects dependencies among other things.
These things still matter even when doing shared hosting b/c you absolutely need to debug your app (client and server side). You can do this adequately with Express with some caveats (cant attach to an arbitrary process, client side javascript debugging is a pain), Standard makes this MUCH easier.
For publishing/deploying - I would recommend 'Web Depoyment Projects' - an MSBuild extension that you can download from MS. This gives you a lot of customizability of how you want to build and deploy your website - which can include sending it to an FTP site. If you have ever used MSBuild and like it - Web Deployment Projects are the easiest hook to extend your build process with an ASP.NET website.
We currently deploy web applications by creating a database and running SQL scripts through query analyzer. Then we copy the output from "publish website" and set up that website in IIS.
We have seen websetup in visual studio, but that part seems to be thinly documented. For example, we are not clear how to ask the user for IP and password of SQL server. We also tend to get websites deployed this way coming up under folders like http://example.com/project, instead of just http://example.com.
Then there are issues with AJAX.Net not being installed or some or the other patch not applied.
So far, we have physical access to the servers. Pretty soon though we are going to be shipping CDROMs. What is the practical tradeoff between manual intervention and automation?
Avoid Visual Studio deployment, and automate as much as possible. Web Deployment Projects and NAnt can be your friends!
Briefly, our deployment setup:
We use RedGate SQL to script differences between dev and live database.
An NAnt build file which calls MSBUILD to build the web deployment project (.wdproj), zips up the resulting compiled web app (along with the SQL change script) and then uploads the zip file to the server.
On the server side, there is another NAnt build file which takes the application offline, backs up the database, backs up the website. runs the SQL change script, unzips the new version and brings the app online.
Step 3 is usually run "manually" (one double-click), but sometimes scheduled for late at night. You could do exactly the same from a CDROM, or even write a pretty little Windows Forms app as a wrapper.
Quite happy to give details of the NAnt script if you're interested.
Have you tried using Web Deployment project? There is support for VS 2008 also now..
I deploy mostly ASP.NET apps to Linux servers. Here is my standard workflow:
I use a source code repository (like Subversion)
On the server, I have a bash script that does the following:
Checks out the latest code
Does a build (creates the DLLs)
Filters the files down to the essentials (removes code files for example)
Backs up the database
Deploys the files to the web server in a directory named with the current date
Updates the database if a new schema is included in the deployment
Makes the new installation the default one so it will be served with the next hit
Checkout is done with the command-line version of Subversion and building is done with xbuild (msbuild work-alike from the Mono project). Most of the magic is done in ReleaseIt.
On my dev server I essentially have continuous integration but on the production side I actually SSH into the server and initiate the deployment manually by running the script. My script is cleverly called 'deploy' so that is what I type at the bash prompt. I am very creative. Not.
In production, I have to type 'deploy' twice: once to check-out, build, and deploy to a dated directory and once to make that directory the default instance. Since the directories are dated, I can revert to any previous deployment simply by typing 'deploy' from within the relevant directory.
Initial deployment takes a couple of minutes and reversion to a prior version takes a few seconds.
It has been a nice solution for me and relies only on the three command-line utilities (svn, xbuild, and releaseit), the DB client, SSH, and Bash.
I really need to update the copy of ReleaseIt on CodePlex sometime:
http://releaseit.codeplex.com/