DEV Community

Discussion on: Straight Outta VCS

jasongabler profile image
Jason Gabler Author

Good questions, and the answer does make a difference for the topic. Most of what I produce is Python and PHP. So, my allusions were to real-time, interpreted code, rather than compiled or semi-compiled binaries. I do realize that such a process is unlikely to be be considered for binary deployments -- unless, you want to put binaries into your source control, which I wouldn't do. (As an aside, this is one of the reasons I got out of the business of Web development with Java, C, etc.)

With that clarification, yes, I git clone to my production server, and then git checkout -b prod, etc., right into the expectations of the Web server's configuration.

jcsh profile image
Justin Ho

Ah, that clears it up.

I also have worked at a PHP shop which did this, git clone-ing the project from the production server. And I agree, there isn't anything inherently wrong with this approach from the code base perspective since they would be the same / benefit from version control.

The problem I see with this approach is that we moved the point of failure from our code base to our servers. Server operating systems, while generally more reliable, are not infallible. If you only manage a single production server this isn't a problem but managing a highly-available environment poses greater risk in mis-configurations / more points of failure or requiring more man-power to maintain it.

Instead, since we ran production servers on AWS, it was fairly simple to use IaC tools committed to version control to create infrastructure and roll out code deployments at the same time.

So I think its not that git cloning is bad, but that it gives greater control to roll out code releases alongside infrastructure releases / changes.