Why you should not use git for deployment

Kevin Simper
Nov 2, 2015 · 3 min read

Deployment has always been hard and there has always been the problem on how do you transfer your files from one place to another and be sure that they are 100% the same.

Here are the drawbacks when using git

1. It does not help you locally

When you use git, you still has to figure out how to set up and test your code on your own computer.

2. You don’t know the final result of dependencies

It is normally ill-advised to commit your dependencies into your Version Control because it makes the history of the commit more difficult to read. Therefore a lot of projects has a way to specify what version of a dependency you have, but lately with the notion of using small modules, you never really know what dependencies you get further down your dependency tree.

3. You don’t test what is exactly going to production

You probably already use a Continuous Integration services (or you should!) and if you test your code only using git as a way to transfer your code, you don’t really test what is going to production. The fact is that a lot depends on the environment that the code is run upon and keeping your development environment, continues integration environment and deployment environment alike is a huge task!

Git has solved efficient file transfer, but..

git is for version control and not meant as a way to deploy your project.

If you use git for deploying your code you still have to figure out how to configure your servers.

But it does not have to suck!

First of all, stop using git for deployment and use it for what it was originally intended for, version control!

The is a pretty good solution for the problem and that is containers.

Now i hear some of you say, “Yes I know about docker” and that is correct, but docker did not invent containers, it was initially based on something called lxc which was released August 6, 2008, and there were even earlier similar projects. This means that docker is just a means to solve the problem, but you could easily use CoreOS rocket container format.

What all of those open source projects was missing was the !

The tooling to easily

  1. package your app
  2. transfer your packaged app
  3. start your packaged app

So by using containers/docker you easily solve the three main problems!

1. Containers help you locally

Yes it does help you locally, you can easily start a container on your own computer.

2. You know the final result of dependencies

Yes you do know your final dependencies because when you package your app, you inspect all the files both before the go into the container and after when they are inside the container.

3. You test what is exactly going to production

When you create your container, you combine the source code together with the code that needs to run it, this way you can run your tests against the code that goes to production.

There is a huge win with using containers and these are just some of them when talking about the file-transferring process of deployment.


Do you want to get started with containers?

Docker has three good introduction videos you can see it here:

Do you want to deploy a container?

We are working on a very simple way to deploy a docker container, try it out at www.blackbeard.io

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store