16 Mar 2012
Link to this post
05 Sep 2013
in reply to
We specifically exclude the App_Data/Sitefinity and App_Data/Storage directories.
Our production instance is the definitive instance, as we have multiple content authors working on that at any given time (We actually run three instances of every site, dev, demo, and production, with scripts to do synce from production down, but never the opposite direction). Because any work done on that instance might change a config file, we specifically do not ever overwrite those. For instance, module builder stuff, which we use a great deal.
Our devs all work locally. From time to time, we pull down the database and config directory wholesale to refresh our local as needed (Usually, this is part of our upgrade process).
Now you brought up a point I may have missed which worries me: We were under the assumption that config file changes ALWAYS occur from the app itself during an upgrade, just like the database upgrade. Is it possible that our config files are getting out of sync with this setup? I know the project manager does add .svc files from time to time, so it apparently does do more than just dropping binary blobs in the bin directory... but your statement about it not touching config files seems to indicate that this is NOT the case. And what about the web.config file changes, etc.? Maybe the upgrades really are as hard for everyone else as it is for us in that case...
Essentially, when we do an upgrade, we blow out our library references location (bin), copy over the new ones from a new project (This handles deletes), and relink everything in our project. Then we go through and manually diff the web.config file to a new project to make sure we got those changes. Then we blow out and recopy over the Sitefinity directory to get all .svc files, and make sure they are all in our project.
Our CI server handles deployments right out of the repository via build script which uses WebDeploy to PACKAGE the site (so web.config transforms run), and then we copy the package files over. Note this requires ALL files that must go over to be in the project properly, as WebDeploy ignores anything that isn't. Also note that since the App_Data/Sitefinity directory isn't in the project, it gets skipped completely (Of course, it's empty on our build server since it isn't in our repository at all anyway).
Right now, I'm considering the following:
1. /lib/Sitefinity repository directory to contain all bin files. Continue our "wipe / copy from empty project" workflow.
2. /src/Sitefinity project with "bin" excluded and App_Data/Sitefinity and App_Data/Storage excluded.
3. Connectionstrings moved back into web.config
4. Setting up a local internal NuGet server to distribute shared code between sites (modules, etc.). This is easier than copying between them as things upgrade. (Note, see my other currently open thread. I'd love to see a project file that abstracts the 16 common libraries that have NuGet packages available for Sitefinity, but I don't see managing the versions myself and creating it myself... it would mean every upgrade would need to have the packages.config file manually checked, when it would be much easier for Telerik to do it from their side. It also removes about 30 megs from any given development distribution / repository commit for an upgrade...)
The biggest issue I really see would be if the upgrade process really touches those config files, because those changes would never make it up there. I DO see that in one of our sites that has been traditionally upgraded this way, the DataConfig.config file is missing a bunch of "urlEvaluators" that the new site has... namely all the new Ecommerce ones... which we don't use anyway, but it makes me think I may be missing something now.