3

I work in a small team that creates and maintains quite a lot (> 100) of ASP.NET website projects. Our current workflow is that our projects are all located on a network drive, which everyone works from directly. We have a couple of shared code libraries, which contain both binaries and css, js and xsl files. With each addition to this shared code, the files are distributed by copying them to all projects on the network drive using a script.

Our current project "layout" looks something like this:

Shared code project
   |- Deployment (compiled binaries)
   |- Library (C# source code)
   |- Web (a website project that contains the default css, js, etc)
       |- css
           |- default (shared css code)
       |- js
           |- default (shared js code)
       |- xsl ... etcetera

Website project
   |- Bin (shared code binaries)
   |- css
       |- default (shared css code)
       |- specific (project specific css)
   |- js
       |- default (shared js code)
       |- specific (project specific js)
   |- xsl ... etcetera.

I'm currently in the process of trying to get us to switch to using git and working locally on our own machines. I've got most potential issues covered, except for how to deal with the shared code. Obviously we can no longer use the copy & replace script if we're all working locally. So something a bit more sophisticated will have to be put in its place.

If I was using SVN I might use svn externals to reference certain files in the shared code repositories. The nice thing with that is that I can pick just those files I need (no C# source code), and put it exactly where I need it to be. But with git that doesn't really seem to be an option. I've been reading a lot about git submodules and subtrees, but neither seem to be the ideal candidate.

I have also considered using a package manager like NuGet or Bower, but is this really a good idea for first-party dependencies? For one, it would mean that everyone who would want to git clone a website project would have to have the package manager installed.

What would a typical git setup for a website project with "first party" dependencies be?

A few details that I think are relevant to the choice:

  • I only need one-way synchronizing. Changes to shared code are made in the shared code libraries. I don't need to be able to push to shared code libraries from a project library.
  • The shared code libraries are updated and distributed relatively frequently; a few times per week at least.
  • Both shared code libraries and website projects will be git repositories.
  • I don't want to pull in the C# source code for the shared binaries.
  • This may help: stackoverflow.com/questions/2140985/… – paj28 Jan 13 '15 at 19:54
  • 2
    @paj28: I'm not 100% sure that git submodules are going to be the answer to this conundrum. I've read many posts that discourage it when the shared code changes often. Also, it would require a sort of "code to deploy only" repository. – PJanssen Jan 13 '15 at 19:59
3

You could stand up your own, private NuGet package feed on an internal server in your company. Publish each dependency to your NuGet site as a separate package and use NuGet to manage those dependencies. Furthermore, if you need to make code changes to a package you can create a local package feed so you can change code, compile and update. When you are ready to share with coworkers, tag and push in Git, then publish to your company feed.

Hosting Your Own NuGet Feeds (NuGet Docs)

The nice thing about this approach is you get backwards compatibility with your packages. You can make API breaking changes without requiring other projects to be on the same release cycle as yours. As an added bonus project structures probably wouldn't be affected if you change source control systems.

  • +1 for NuGet. Once you figure out how to get everything set up, your life gets so much easier--your dependencies can't break your other projects until you specifically want them to. I've just started using NuGet in my dozen different personal projects, and it's made adding shared features so much easier. – mgw854 Jan 14 '15 at 4:30
  • Do you have any tips on how to automate this process? Since these packages are updated quite often (a few times per week at least), it would be great if there were as few steps in the release process as possible. – PJanssen Jan 14 '15 at 6:42
  • You might be able to use a Git hook. When you push a tag ref to your Git repository, maybe it could package and push the NuGet package. – Greg Burghardt Jan 14 '15 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.