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.
Related
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)
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.
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
i have requirement. i have created the window application and i have created the setup of that application that has been installed to client machine.
Now the requirement is that if i will do the further modification to the project the client not need to install whole application again instead client only need to install Update of new version. like using Patches or something. How can i do this is there and tool in VS from which we can create the update patches or something.
Please Help..
There are several options, but they depend on which installer you used in the first place.
It is very easy with Inno Setup, as (if the file items are configured correctly) InnoSetup will detect that the application is already installed and only copy modified files, even though you publish the entire setup. This will be automatic.
If you used the built-in Visual Studio setup project, it is also possible, but you must set a different "upgrade id" in the setup properties. I haven't worked much with this, yet.
A third option is using Windows Installer XML (WIX), which is able to generate patch installers, but I haven't worked much with WIX yet.
One last option would be to write something yourself that is able to exchange old files against new files, but you'd have to keep UAC in mind for newer Windows versions.
I have solved the problem...using ClickOne Setup of VS. i publish the win form to a specific URl and each time when application launchs its check the Upgraded version if available it install and run.
http://www.15seconds.com/issue/041229.htm
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)