I run my production software from production branch, working copies. I have been told many times that this is a grave sin. Yet, I have been doing this for over six years in my current gig (out of twenty-eight years as a professional), which includes scores of deployments to production and hundreds to stage, without a single problem related to this practice.
At my most previous job, I was required to export from our VCS (initially svn and then git) to generate the executable production copy. All this seemed to do was to add extra steps to deployment, making more room for mistakes or things to break. It also made hot fixes that required work on the production platform (for example, as the very last resort when the error cannot be replicated anywhere else) frustrating and unnecessarily complex right during the middle of a time when developers or devops need be the least distracted.
The only argument I've encountered against this practice that was even slightly compelling to me is that I might mistakingly deploy updates from that branch. Well, what if I were to mistakenly do anything? I can do a lunkheaded export from git just as easily as I can do a lunkheaded update from git. From what I can see, rolling back, moving among branches, etc., are far easier to intentionally accomplish with my scheme and yet no more or less as error prone than any other scheme. After all, I do not merge into my production branch until stringent testing and multiple sign-offs have been collected through dev and stage.
What do you think?
Allow me to finish by saying that I'm not intending this to be a discussion that intersects this question with the larger topic of deployment strategies, such as using things like Docker or various forms of CI, and so on. We're just talking VCS, keeping it simple and focused.
Thanks for taking a look.
Top comments (3)
Thanks for the write up Jason!
I'm still unclear what you mean by "run [your] production software from production branch" and "export from [your] VCS to generate a production copy".
Do you mean that your software is compiled to binaries, and then checked into version control on a production branch? Or do you mean
git clone-ing your project's production branch from your production server?Just clarifying how your workflow works without a greater deployment pipeline.
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 cloneto my production server, and thengit checkout -b prod, etc., right into the expectations of the Web server's configuration.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.