Managing releases (binaries and othert build artifacts) using Git

Question

E_d is an environment where one can develop, build and test a .NET web application.

E_p is the production environment, where only running the application is possible. That is, build is not possible.

Repo_src is the source code repository.

Now I would like to implement a poor man's application update mechanism (for binaries, configuration and other assets). How does the following sound to you?

Create Repo_bin, a Git repository which is accessible from both E_d and E_p. In order to release a new version, build the application and other assets on E_d and git push the changes to Repo_bin. Add a git tag for the revision as well. On E_p, do a git pull. The new binaries and configuration replace the old ones.

Advantages: quite easy to git push & git pull as opposed to manually creating a software patch and an upgrade script for each release.

Answer 1

Git is not a deployment mechanism. It is a distributed source control tool. You are creatively using the “distributed” part to manage and deploy your artefacts, but that is not playing to Git's strength. Instead, storage of binary assets is a weakness of Git, because

• this results in a very large history, and
• no meaningful diffs are possible.

I have worked with large repos containing binary assets. This was unavoidable (because the collection of binaries had to be version-controlled), but it's an experience I don't recommend.

It is possible to do a shallow clone where you only download the top few commits rather than the complete history, but that complicates the Git usage, and means that you don't have a fully functional repo available.

Git is also a really bad deployment tool, because Git is concerned about files, not about processes or services running on the production system. You will typically want to setup script that can stop and restart relevant services.

If copying files into a particular folder is sufficient, then write a script that

• builds a release, then
• copies the release to the production environment with an FTP-like program. (But not literally FTP, because it transmits passwords in plaintext.)

If you need a more sophisticated deployment, write a script that

• builds a release,
• remotes into the production environment,
• uploads the new release,
• stops the old processes and restarts from the new release, and
• cleans up old releases.

Maybe there is a friendly Sysadmin or DevOps person around who can assist with these issues. There are also a ton of existing solutions specifically for managing your artefacts. I think in the .NET world, hosting your own NuGet repository is a common and definitively superior approach.