I have several ASP.NET application running under a common IIS Site and would like to use a NuGet package to transform their config while copying versioned JavaScript file to the IIS Site's Root application Content folder.
Can NuGet be used like this? I.e. can it be determine during package installation/updating which IIS Sites root application an ASP.NET project is being run under (using the preinit powershell script for example).
The tool you are looking for is Octopus Deploy It install nuget packages on IIS, as windows service, etc. Moreover it gives raeally nice GUI for management.
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
Related
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
All the deployments in my work place are manual. I have been looking at ways to automate all of this using MSBUILD and MS Web Deploy. What I have managed to get working is as follows:
build/compile solutions
run database migrations
deploy directly to website using ms web deploy
All from one MSBUILD script.
This differs slightly from the manual process, as when a new version of a website is deployed manually, it is put into a new folder that is datetime stamped. And then IIS is pointed to the new folder.
My question is, how would I do these last 2 actions? i.e. write to a specific folder that sits a level higher up than the folder the current website points to, and then repoint to the new folder IIS.
Web Deploy does not support this functionality directly. Thankfully it does provide the runCommand provider, which is what you'll end up using.
%windir%\system32\inetsrv\appcmd.exe is the utility you'll use to swap site directories. An example of usage can be found here: How do I change the physical path of web site in IIS7 with APPCMD?
Create a script that calls appcmd. This script will always sit on your destination server. You can either decide to include it as a part of your site deployment, or move it along into the new directory from the old one. The "web deploy user" on the destination machine needs to have the appropriate credentials and access to create directories.
In your MSBUILD script, prior to deployment, call the script on the destination server. E.g.
msdeploy.exe -verb:sync -source:runcommand="C:\path\to\wwwroot\bin\script.bat"
-dest:auto,wmsvc=https://contoso.com:8172/msdeploy.axd,username=%username%,password=%password%
Then deploy as usual
NOTE:
Try to avoid this way of deploying entirely. If you're looking to snapshot your site, consider deploying to a package (zip), and then deploying that package to your destination server. Rollbacks should be handled by deploying an older package, not by repointing to an older directory.
We are currently using web deploy for creating packages for our .net web applications. It got some pros and cons. Now we are going to use nuget for dependency management but given the ease of packaging in nuget .. i am debating on should i still use web deploy + remote service or try to use nuget to bundle my web application and use powershell or something like octupus to deploy ??
For my web deploy becomes little complex when even try to do simple things like include , exlcude , gac or registry or iis config ( which again not very flexible ).
But on the other hand it comes with remote service and all i need to do is through the package to the service and i am done..
Please give your inputs on this comparison.
-raj
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time. From a deployment perspective, it doesn't offer you any more than what a zip file does... except all the overhead of trying to fit NuGet in the process.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I am setting up a system that uses NuGet and Webdeploy.
NuGet is used as the repository format, so the build system publishes NuGet packaged artifacts.
The Deployment systemn uses NuGet to get the RIGHT packaged artifact from the NuGet repository.
The build artififact happens to be WebDeploy for easy installation.
I am still working out if I am going to use puppet, chef or octupus to orchastrate the deployment.
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.
With VisualStudio Publish, CruiseControl.NET, MSBuild, aspnet_compiler.exe, and Web Deployment Projects out there, how would one know which tool to use to ultimately get a .NET 2.0 web application into a testing/production environment?
With .NET 1.1, I simply copied all files over to the server's directory and set it to a configured virtual directory in IIS. Unless I am really missing something, it seemed to work just fine. Now I'm reading about how important it is to put some good thought into 2.0 deployment and the the more I read, the more I get confused.
Please breakdown how to choose which tool to use, and why you would use that tool. If more than one tool is needed, please identify how they relate to this process.
CC.NET is for Continuous Integration it can build your setup projects as artifacts, but that is not it's main purpose. MSBuild is the Microsoft build system -- again, not related to deployment. aspnet_complier compiles your web sties, which may make deployment easier, but is not in itself deployment.
Web deployment projects is what you should be looking at. Here's a decent little post that goes over some of the options for deployment and a reference from MSDN. There are also commercial products.
In most cases, you can right-click on project in VS.NET and choose "Publish". This will give you a few options for deploying via FTP or file path.
Publish Web http://img26.imageshack.us/img26/1261/screencfl.png
What we do it publish to an SVN repository, then run SVN UPDATE on the machines it needs to go to...
I use TeamCity, which implements
Rebuilding solution with
devenv.exe in command line
Changing settings in web.config
(connection strings and debug mode)
with sed.exe
Precompiling WebSite
with the aspnet_compiler in command
line.
Copying solution to FTP
(with internal tool)