VCS repository layout best practices

Thought I would start this thread on best practices for VCS project layouts to see what some other people are doing.

Typically, we do the following:

1. Typical OSS repository structure (/src, /tools, /build, etc.).
2. Solution and all projects under /src.
3. All Sitefinity project binaries moved out of bin to another location so solution wide clean events don't wipe everything, etc. Project references all updated manually to point at new location (* this is what I'm looking for a better solution for mostly).
4. Connection strings moved back to web.config to utilize web.config transforms for deployments.
5. App_Data directory and bin directory excluded from repository.

The problem with this setup has traditionally been that upgrades are a pain. Every upgrade, we have to manually copy over all of the new bin directory stuff, check all of the svc references, and make the web.config changes that need made.

I'm wondering what others are doing to solve some of these specific issues:

1. Keeping bin refereneces out of the repository that don't need to be present. E.g. my projects that will be compiled into it, NuGet package references, etc.
2. Allow for easy LOCAL upgrades (Thunder is a no go for us) through project manager?
3. Easily usable in CI environment (e.g. PowerShell scripted deployments won't be affected).

My main concern is the upgrade process as we stay pretty close to the latest version at all times. Having to manually copy, remove old DLLs, and reassert the locations in the project file sucks as a workflow, and I don't trust anyone else here to do it besides me, so I'm questioning if there's not a better way to do that which might be closer to the simplified deployment model that Telerik seems to assume.

Hi Michael,

The steps that you have listed seem OK with the exception of step 5. Can you please explain why you are excluding the App_Data folder? Since it contains themes and configuration files, it would normally be kept in source control.

Sitefinity assumes that the version of assemblies, configuration files and DB are always matching in a healthy site. If you change the BIN files but avoid changing the config files, this could create issues. Excluding the other BIN files that you mentioned is OK, even advisable.

Also, about the Project Manager upgrade that you asked - this is not as smart as many people assume. What the project manager does is just copying the new binaries over the old ones. It does NOT modify configuration or touch the DB. Upgrading is a matter of changing the BIN files, and then launching the project to let Sitefinity change the config file versions, as well as the DB.

Most source control systems have some concept of ignore files, where you can specify concrete files or patterns that should be excluded from source control. There are community generated files for .NET projects and you can usually use such files with Sitefinity.

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.