This project is read-only.

Deploying from source code using version control?

Topics: Administration, Installing Orchard
Jul 13, 2011 at 1:05 AM

We have all the sites on our server checked into version control using our Perforce server. For our own ASP.NET MVC 3 web sites I have a build system that determines what files have changed after a build, and then deploys those into our live tree. This always pics up the DLL's that we build every time (unfortunately due to the build timestamps in a DLL in many places I have not found a way to compare two DLL's and see if they are identical or not :( ).

Anyway, the core issue is I am trying to work out what files I need to deploy in source code on the live site to make this work. Should I just deploy the entire source directory along with the basic binaries from the Orchard.Web\bin directory, or is it possible to deploy just the view files and pre-compiled binaries for all the modules if I am building everything from source code? I know Orchard does dynamic compilation to make it easy for new modules to be installed, but we want to fully control everything that is on our server, so don't really need the dynamic compilation system but it is not clear if it will even work if I don't deploy the source code to the production site or not?

Any suggestions?

Jul 13, 2011 at 11:25 PM

You only need to deploy the contents of the orchard.web folder. But even that is too much, you will want to exclude all bin & obj directories of all modules. The Visual Studio deployment should give you an idea of what you need to deploy. Cracking open the WebPI package may also be a good thing to look at to see what's necessary.

Jul 13, 2011 at 11:25 PM

Oh, and yes, you need to deploy the source code for the modules at least.

Jul 13, 2011 at 11:41 PM

Yes, that is what was throwing me. It seems without the source code the modules won't work, so they need the source code to be deployed, but they don't even really need the binaries since those would get built dynamically when the site fires up the first time?

For now I just dumped the contents of the WebPI package that I managed to build (found the build.cmd file in the Codeplex tree) into my Perforce tree, and then just started with that and install the modules I needed from the gallery. Then I will import any changes done by us and our designer back into Perforce (but it will also pick up the binaries at the moment, but that is OK as I set everything up to be read/write so the files are writeable). Not perfect, but it will work to get us going and then I can work out a locked down system in the future.

It did confuse me that the WebPI package that is built does not contain everything in the source tree, just the basic stuff. I had expected everything to be in there, but I guess it is faster to not have modules installed if you don't plan to use them?

Jul 13, 2011 at 11:58 PM

Correct, the modules will get built dynamically, so they need the source code. And yes, we opted to make only the modules that everybody needs in the distribution, given how easy and fast it is to install new ones from the gallery.

Jul 19, 2011 at 2:23 PM

So how then can I keep my source control repo up to date with a deployable version of my site when I need to install modules on the live system by hand?

I see two ways to accomplish this:

  1. Either I include modules I want to use on my site in source code form into my repository (and subsequently have them included in the build output files), additionally needing to modify some config file to include that module (haven't got there yet), or
  2. I install my site on a staging system that has access to source control - there I'd install additional modules through the gallery and then push those changes to the central repository.

Are these the only two ways to achieve source control coverage for the whole site or am I still missing something?

Jul 19, 2011 at 7:10 PM

Just for information:

I went with option no. 2. We installed Orchard using the zip, pushed everything to github, and are now working on several local copies of this repo. We can install modules, edit content and so forth, and once we're done, we can just push the new version and deploy it to the live environment. The DB is copied as well since it's a simple company's site where we don't need any staging setup or development DB.

For future development I will still have to figure out how to separate these environments - but for now I've got a working setup.

Cheers, Oliver

Jul 19, 2011 at 7:15 PM

Did you try using the ClickToBuild.cmd file to build the deployable version?

Jul 19, 2011 at 7:19 PM

Thanks for coming back here. I did use the ClickToBuild.cmd for the source code install after reading

But as far as I understand, the manual install does not demand that step (and in the zip the file is also not contained).

So it's basically just an xcopy deployment right now. Works.

Jul 19, 2011 at 7:23 PM

What you're doing is hardly typical, so... Xcopy works, if you are ok with deploying 500MB of dead files. ClickToBuild will do a clean build with just what you need. If you want to put the output of that under source control, it should work fine. But maybe I misunderstood what you're trying to achieve.

Jul 19, 2011 at 8:13 PM

Ok it seems like I've mixed up a few things. Sorry for that!

I'm new to Orchard and trying to find the best suitable way to build an app on top of it, version controlling everything needed to run the app on a live server (dedicated).

I've explored the source code solution and have successfully built it using ClickToBuild.cmd getting a Stage and MsDeploy output folder. The MsDeploy folder is 23,6 MB in size, the Stage one weighs in at 42,7 MB. From what I can see, the MsDeploy folder does (almost) not contain compiled dlls in the Modules folders. To me it felt a bit awkward though importing the whole solution into a (git) repo to run a simple site on top of it.

So I went to look for a smaller alternative and installed Orchard using the zip that simply contains the application to run. No ClickToBuild.cmd there - and no need for it. And I thought I'd just take that application and deploy it since I don't need anything else for this small site. There I also have only about 24 MB of files to deploy which is perfectly fine for us (not 500MB, since I was not referring to the source code solution).

Does it still seem awkward, what I'm doing here?

Thanks for your guidance.

Jul 19, 2011 at 9:19 PM

The thing is, what is in the zip and what you'd get from ClickToBuild are identical (because that's how we build the package in the first place). Doing ClicktoBuild yourself and using the output of that has the great advantage that you can update your local copy of Orchard at any time. The zip, contrary to a clone of the source, is not under source control, so it will be harder for you to upgrade in the future.

Jul 19, 2011 at 9:36 PM

What I would like is a 'fullbuild.cmd' file that would build everything and include it in the ZIP file, not just the stuff in the core distribution. That way when I do a build from source code, I can easily clone the resulting tree into our source control system to push to the live site. If we made mods to modules out of the core codebase, those mods are lost unless we manually deploy the files.

Jul 19, 2011 at 9:42 PM

@kendallb: As far as I understand, what you are saying is not quite correct. Since the modules' source is physically situated underneath the Web project they will well be included in the build output that ClickToBuild .cmd generates. And that's all you need to run your site! Regards, Oliver

Jul 19, 2011 at 9:47 PM

That's right. The set of modules included is of course a variable here.

Jul 19, 2011 at 10:01 PM

But they don't end up in the ZIP file that gets built. It only include the core modules, not ALL the modules in the source tree.

Jul 19, 2011 at 10:33 PM

Yes they do. All modules present in the site when you run clicktobuild will end up in the package.