4

I have a visual studio solution with some (about 20) projects. Source control used for this solution is git.

Those project are built around an existing application server (closed source, binary only). The application server consist of about 300 files / 140 mb. The version of the application server can change 6 times a year (if new features/bugfixes are needed) The developer needs this application server in order to test(integration tests) the development.

Most of those projects have references to some assemblies of this application server (i.e. in order to make a connection). There are about 15 files, for which we create NuGet packages which are hosted by our self.

Some projects may have references to official nugget packages.

Some projects may have references to 3rth party assemblies which are in a “lib” folder and are part of the solution. The lib folder is also part of the git repository.

Question:

Where and how should we put the application server files?

Version 1:

Put into an app folder next to the lib folder and add it to the git repository.

  • Pro: Developer can just git checkout and is ready to start the app server. Developer can work offline.
  • Cons: Lot of binary files in git repository. Will result in a huge git repository.

Version 2:

Put a robocopy script into post build event, and copy the app server after successful build from a network share or internet.

  • Pro: Developer can just git checkout, build solution and is ready to start the app server. Git repository will remain lightweight.
  • Cons: Developer need to be connected to the network/internet, otherwise the post build event will fail, and therefore the whole build will fail. It is slow if the developer checkout a lot of different branches, since it will download the application server for every checkout.

Should we go with one of the above mentioned versions? Are there other possibilities/best practices how such a scenario can be solved?

Community
  • 1
  • 1
Manuel
  • 1,985
  • 3
  • 31
  • 51

3 Answers3

2

You should use an artifact repository. This is exactly what artifact repositories are for: "source control" specifically for binary artifacts.

I have no experience with NuGet artifacts, but I see from JFrog that artifactory supports NuGet. There's a pros v cons answer about this here on SO.

While I generally prefer nexus over artifactory, the accepted answer in that question makes a compelling argument for artifactory in this case.

Community
  • 1
  • 1
Paul Hicks
  • 13,289
  • 5
  • 51
  • 78
1

An artifact repository like @PaulHicks suggests sounds ideal.

However, if you do not have the time, infrastructure, or know-how to take this approach (to start), I humbly submit that I think you are somewhat overthinking this for 140 MB - that you somewhat overstate the downside you note...

Cons: Lot of binary files in git repository. Will result in a huge git repository.

...and should strongly consider just going with Version 1.

If you already maintain Lib with referenced binaries in the source repository, an additional 140 MB does not seem like a big deal to me - especially in light of the big benefits you note:

Pro: Developer can just git checkout and is ready to start the app server. Developer can work offline.

Another benefit to Version 1 (that admittedly also would come with updating the app-server package to use taking the artifact-repository approach) is having a clear history of the app-server versions employed by the solution.

J0e3gan
  • 8,740
  • 10
  • 53
  • 80
1

The proposed Version 1 is workable and this is what I would go for, with one slight modification. I'd manage the app folder as a standalone repo and consequently as a git submodule.

Tagging and versioning in the repo of binaries has both the advantages of having everything ready to go in one place and also the freedom and ease to switch to another version of the binaries for testing purposes.

That said, if I was a developer working in such a setup I would probably ignore my own advice about submodules and manage this as follows:

  • git clone the app repo of binaries on my machine1
  • git clone the dev repo and create an (ignored2) symlink to my app repo

That way I can enjoy the best of two worlds, the code and the binaries are versioned separately, but I am always ready to go, because the combination of the two repos allows me to work offline, pulling and pushing when necessary.

To summarise, I think you should just provide two repositories. One for the binary artefacts and one for the source code, and while you can provide a suggested "howto" blueprint, you should also let your developers the freedom to surprise you with their ingenuity.

1 If multiple clones needed or file sizes getting out of hand, I'd use git annex
2 How does git handle symbolic links?

Community
  • 1
  • 1
mockinterface
  • 14,452
  • 5
  • 28
  • 49