We are using agile project management and follow sprints to do development. We are using a single repository in bitbucket.org that uses mercurial. Repository is hosting 3-4 products. There are many projects with 4 solutions for each product. There are some product specific projects and there are some shared projects.

We cannot do changes in the folder structure sine we already have a team city server that is doing automated builds which works well. But I am open if its really critical to handle it.

Current Process
Our current process can be described as follows:

  • during development, we use hgFlow start and finish features (develop branch)
  • for releases, we start releases, make them stable, finish the releases (new release branch from develop)
  • for hotfix we start hotfix (new hotfix from release branch), and finish it (merges to develop and default)

Here are some of the problems with this process:

  • when we start release, there are 3 other product's code which is not ready to release, is also present in the release and when release is finished, goes to default which is unwanted.
  • when we change shared projects in development, it affects open releases and we have to patch it ther
  • when we change shared projects in release, it affects previously released products

there are so many other technical issues that we discovered and we immediately stopped using hgFlow, and right now doing manually folder diff in order to start/finish release and hotfixes.

Some of the options that I thought of

  • Create single repository to host each product's source code except shared product
  • Create single repository for each of the shared project
  • Separately maintain HgFlow and Tags etc.

That is too much work, say for example, when I want to start release, I have to go to product and each affected shared project to start a new release. same is true when doing regular development, for a single feature, if I want to change product and shared project, I have to do create feature in all of the projects.

How to better handle it?

Update - 9 feb 2016 Our products are based on .net, we are using bitbucket for hosting, mercurial and source tree with HgFlow for development operations.

  • Do you use a package manager (nuget, gem, npm, bower, etc) to deliver those shared projects to your applications? Or do you link to the project and build it directly into the application? If the latter, that's the problem you need to solve, I suspect.
    – pdr
    Feb 8, 2016 at 9:06
  • Currently we are using project reference since its easily resolved by team city at the time of compilation but open for suggestions. Feb 8, 2016 at 11:00

1 Answer 1


Set up a company-level nuget repository. (I'm assuming .NET from the terminology you're using, but there are equivalents for almost all language frameworks.) Either build one on your own server, or use a service like myget, or simply use your TeamCity server's built-in nuget feeds.

Deploy your common code in packages to that repository, as an entirely different build in TeamCity. So, assuming the simple scenario of solutions A and B with common code in project P -- project P gets removed from Solution A and B and moved into it's own Solution, which builds one or more nuget packages.

Those nuget packages are included as references in any project that needs them. Just like packages from a public nuget server, except you have to tell Visual Studio where your package server is.

Now you can manage your branches in a project-level Mercurial repo, independently. The process for releasing code into the common project is:

Repository P

  • Start feature
  • Make changes
  • Finish feature
  • Start release
  • Increase version
  • Build
  • Deploy
  • Finish release

Repository A

  • Start feature
  • Update package
  • Finish feature
  • Start release
  • Increase version
  • Build
  • Deploy
  • Finish release

(For the record, you appear to be largely using hgflow, even if you're not using the command-line shortcuts, so I'm using that terminology here.)

Does that seem like a lot of steps? It is. But they're all tiny steps. Once you've done it for a while, it becomes kind of second nature.

And, most importantly, you'll notice that you haven't yet affected solution B. That's good. Your biggest problem has been solved. You colleague can continue to develop solution B without accidentally drawing your changes in. When one of you is ready, you can upgrade the package in solution B.

If you use beta releases (eg. 4.0.1-beta01) for untested code, your colleague won't accidentally pull in a change that you haven't tested yet (or as we like to call it, a bug).

This process is not without cost though.

In particular, you have to be careful of nuget dependencies. The more you have, the more heavy-weight the process to make changes to the bottom-level project. Better to have more projects or bigger projects than more dependencies.

  • 3
    This is IMHO a good answer, but I guess the suggested use of "Nuget" distracts from the core point. What's important is to have strict versioning for the shared components, and allow product A to be linked with library P Version 1.0, whilst simultanously product B is linked to library P Version 2.0. And whenever P is changed, one has to decide if the change is a critical bugfix (so P V1.0.1 and PV2.0.1 is created), or a new feature for the V2 product line (which yields to P V2.1 or P3.0, but leaving PV1.0 unchanged).
    – Doc Brown
    Feb 8, 2016 at 13:22
  • 1
    Note that TeamCity can be the package repository i.e. the packaged artifacts from a build can be published directly in/from TeamCity with no need for any other server.
    – Murph
    Feb 8, 2016 at 13:47
  • @DocBrown Fair point, but I think package managers are easier than any other approach to ... managing packages. Personally. I will accept there are other ways.
    – pdr
    Feb 8, 2016 at 14:09
  • @Murph: Did not know that. It's been a while since I've used TeamCity (probably v3). Will add a link to that.
    – pdr
    Feb 8, 2016 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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