Large solution, a dozen projects : Teamcity + Octopus

Legacy Modelling
1

Hi

Here is the situation :

  • Pretty large Monolithic Visual Studio solution 60+ projects including :
  • 12+ Web Projects (asp.net webforms / MVC / Web API)
  • 5 Windows services
  • 40+ C# project libraries (used by most of the web projects and windows services)

Solution Logic

  • All the projects (web and windows services) shares all the other dozens C# class libraries (this is the issue)

Infrastructure :

  • TFS Server with Git
  • Team City Server
  • Octopus Server
  • 3 Web servers : Dev, Test and Production (all with Octopus Tentacle installed)
  • 3 SQL servers : Dev, Test and Production

So far I managed to :

  • On code commit, build the whole solution on TeamCity Server.
  • 1 Teamcity project only, configured with 3 steps : Nuget Installer, Build Solution sln, Create Release.
  • This is building the solution, generating the artificats for projects including OctoPack and triggering the release on Octopus
  • Octopus is reading from the TeamCity feed. I have only one project in Octopus with one step per web project to deploy IIS website.

The issue is that I am not sure if I am doing the thing right, I think I have not correctly splitted everything and I am kind of doing a hammer style deployment.
Each time I do any commit in the solution, it is basically rebuilding everything and publishing everything.

I know that there is not a perfect solution but I have the feeling that I am not splitting everything like I should

2

Hi,

Due to the way your solution is structured, it makes it very hard to rebuild/publish/deploy individual parts of the solution.

You would need to re-architecture your solution to make your continuous integration/deployment pipeline a less “hammer” style implementation.

I hope that helps a bit.

Thanks,
Henrik

3

I have a similar arrangement set up; I think you’ll find most of the work will be done at the TeamCity end of the equation. I created one Visual Studio solution per application (website, service, whatever), which included whichever of the projects were required to make it build. I then set up a build configuration for each application to build those new solutions, and made heavy use of templates and parameters to simplify the process. I use Octopack to create my Nuget packages and upload them to the TeamCity internal feed, and the Octopus Create Release build step to create the release.

Since everything is running out of basically the same repository, a commit will trigger all the builds (still not optimal then) but the builds run faster as I am not referencing the whole suite of projects, just those that each application needs.