I have a number of asp and asp.net 2.0 applications that I need to move to a new Win2003 server.
I've created a test suite to verify that different aspects are installed and configured properly, but other than exporting the IIS metabase from the two servers and comparing manually, are there any tools or techniques I'm missing?
The Microsoft Web Deployment Tool should allow you to do pretty much what you want.
From the linked web site:
The Web Deployment Tool is a tool for simplifying the deployment, management and migration of Web applications, sites and even entire servers. Developers can package a Web site, automatically including content, configuration, certificates and databases. These packages can be directly deployed to a server or packaged and shared with others. IT Professionals can enable developers to deploy these packages to a server and delegate access to non-admins. IT Professionals can also use the tool in their infrastructure to synchronize servers easily on both IIS 6.0 and IIS 7.0, or even to accomplish a migration from IIS 6.0 to IIS 7.0.
When it comes to metabase edits, it allows you to easily get a list of all settings your site is dependent on, and sync these to the target server (complete with a handy 'what if' mode).
What version of IIS? (This will impact the extract steps.)
You can export settings from IIS manager and import.
If you're doing it manually then I'd use something like BeyondCompare to make your life easier.
You could write some code using System.DirectoryService to programatically compare the two servers settings, or compare a given server against an Xml file have a look at this
Look at the sdc extensions for MSBuild they let you create websites in a msbuild file so if you can verify that you can create it correctly you can just add that to your build script.
To use move your application to another IIS.
1) First use ntbackup, and backaup
the applicaton folder.
2) Export the application
configuration to a file in IIS.
3) On the other server use the
ntbackup command and then restore the
files in the same path.
4) Create the application from the
config file.
5) Adjust possible missed
configurations.
6 That's it.
In our company we are migrating many .NET apps from our testing servers to productive ones, and we follow this guide.
Best Regards!
Related
I have a doubt.
How can i create scritps to :
Get my code from repository (GitHub, GitLab...)
Build
Publish
Test
Run in IIS
This script should run in windows or linux OS, and consider that i have a empty VM.
This application is an .Net Core WebApi.
I searched in web but not found an template geting code from repository.
This is doable with scripts like #Scott said and you should consider using solutions for this because there are some great free ones out there like teamcity with octopus integration. Here is what you need to consider if you decide on making scripts for this.
The vm you have is empty so the runtimes need to be installed and
checked are they compatible with code you are trying to deploy to
them.
The scripts for some parts of deployment will need to be run under user with sufficient privileges
You will need to handle the webserver configuration with the scripts as well for all of this
And those only a few things that are on the list for that path. Now having said that there is the path of containers which handle most of this through code and can be deployed to all of environments you mentioned before and you only need to worry that there is a container service on those vm-s you want to deploy to and it will be much easier to handle since like i mentioned it is all in code and is easily changed unlike some scripts.
I am using Octopus Deploy and TeamCity to automate the testing, building, packing, and deployment of a .NET app to multiple servers. Most of the servers have one instance of the app, but a few of them have multiple instances.
I cannot figure out the best way to do this, or even if it is reasonably possible in Octopus.
Can anyone provide a method to do this? I know I could technically script the entire process in powershell, but it would be nice if I could take advantage of the IIS features of Octopus Deploy.
You could set up multiple steps to deploy the same nuget package.
The first one would be the IIS settings common to all servers.
Each additional one could target a specific tag (instance1, instance2, etc) and have the custom IIS settings for those instances. Just tag the machines that have the multiple instances appropriately and those extra steps will only run for those machines.
We currently have CruiseControl.NET (v.1.6.7981.1) running on a 'development integration server.' We have a number of separate .NET sites that operate under the same IIS site and therefore share a 'bin' folder. This is the required setup due to the CMS implementation.
With a shared bin folder, an assembly change from one site could throw an error and affect all the other sites.
What we do is build and deploy the single site that we're currently working on to the integration environment and then spot-check the other sites to ensure they are still working.
In order to have more immediate feedback on the builds, we are looking at utilizing triggers to build all solutions at the time of a checkin of any solution. Ideally, we would like to avoid having to edit each project's configuration when a new site is developed and brought into the integration environment.
Does this sound like a sound approach or is there a better way to go about this?
Thanks!
I Develop one website using magento. How to i Publish on server? If asp.net after publishing
codes are converted into dll . but here magento How It work? How i configure my own website?
Thanks in Advance...
There are a number of ways to do this. From simplest to most complex:
Simple zip and unpack on the server. Migrate databases with mysqldumps.
Push files with an FTP program. Preferably one with a compare viewer, such as Beyond Compare
If you utilize a QA environment or a staging site on the same box or a local server you can utilize rsync to push changes from one directory to another.
Create a source-control repository and use your production site root as a checkout of your Magento application (probably your best bet for ease of use).
Utilize source-control but deploy with a build tool such as Apache Ant.
Implement continuous integration with a tool such as Capistrano, Hudson/Jenkins, or CruiseControl
You really want to be using source control anyhow - so deploying straight from SVN/Git/Hg or another tool makes the most sense as it is easiest to manage and requires very little effort on your part. Making your repository publicly accessible can be as easy as using a free service such as GitHub or Beanstalkapp. Paid levels give you private repos or more than one user.
Continuous integration will be your best bet for rapid deployment on a site that is changing quickly and many deployments happen daily. Some comparison of tools:
http://en.wikipedia.org/wiki/Comparison_of_Continuous_Integration_Software
I hope that helps. I have deployed Magento using all of the above methods. There really is no elegant way to push databases around outside of using upgrade scripts in local modules. You can use tools like Maatkit to diff tables or in some extreme situations I've seen developers alternate between qa and production environments using Magento's built-in table prefixes.
i am interested in creating a setup tool for our business application which is based on a Windows Service and some WF4 workflows, currently hosted in IIS/AppFabric.
As long as i want to provide the best possible installing experience to our customers, I want to include IIS and Appfabric Setup Prerequirements as well as a WindowsService application into one Application-Setup Project.
Is there a proper way of doing this? Can someone give me some Links and/or Tips?
best regards,
Chris
The standard approach is to build a Deployment Package and import that into IIS. Is uses Web Deploy, see http://go.microsoft.com/?linkid=9278654 for more details.
For client deployment using a setup project, I've been a fan of using WIX and an automated build script (MSBuild or Nant) in the past. It allows me the flexibility to script the build of the setup.exe, allowing me to make the changes I need (connection strings) in advance of deploying; leaving the entire process (regardless of environment [dev, prod, QC]) scriptable and automated.
For deploying the workflow components, its as simple as xcopy deployment which, like the above, is easily scriptable and automatable.