On Mon, 25 May 2015 09:30:17 -0700 (PDT) Chris Fillmore <fillmore.ch...@gmail.com> wrote:
[...] > In order to test our changes, the code MUST be > running on the server -- it can't be run locally on our machines. The > server in our office is not a production environment, it's a > development environment. Testing and production servers operate in > our clients' offices. [...] > - Team members push changes to the development server > > Here's where I need advice. How do you go about testing the code in > different git branches on the server? > > I am imagining I putty into the server, checkout my branch, run the > code. Is this possible? That depends on how do you define "possible". Supposedly you want to ask if it's possible to do the "checkout my branch, run the code" bit, right? The answer depends on what constraints "the thing" you're using to test the code has. I'm not familiar with neither of the two pieces of technology you've cited so I can't tell for sure. Surely if "the thing" has command-line interface so you can run it in an SSH session and see its test run results somehow printed back, it is possible. If not, we need further details on how "the thing" is supposed to be controlled when doing its test runs. > But what's to stop other team members from > doing the same, at the same time? Again, suppose you have checked out some version of the code into some directory on the server's file system. Now suppose one of your colleagues did the same with a *different* directory. Does "the thing" allow to run two tests on these different code bases at the same time? If yes, the problem is solved. If not, then, again, we need further info on that tool's constraints. For instance, if it requires the code to always be located in a certain directory and only allows a single run at any time, I'd solve the testing problem using a simple CGI script which would receive a commit hash as a parameter, create some lock file and flock() it, check out the indicated version of the code, run the tests, delete the lock file. That would prevent any of you from running several tests in parallel. Certainly that's a poor man's solution, and you might look at a CI system? Sure, picking one and setting it properly so that it obeys your tool's constraints might be harder than writing a brain-dead solution I outlined above; YMMV. [...] > We debated the option of imaging the server to run on virtual > machines locally on each team member's computer. But I'm not sure if > this is feasible. Uh, why not? Only low-end x86 CPUs (those targetting fanless micro-ATX etc) do not have support for hardware virtualization these days, and you needn't run a server-class OS (you mentioned PuTTY so I suppose your team's using Windows on your desktops) as there's VirtualBox. And there's even no need to use virtualization on desktops as you can just use KVM (or Xen or containers via LXC or Docker or any other light-weight solution) on your server and SSH to these instances. TL;DR Given the description I'd vote for semi-automatic solution using a CGI script because to me this appears to be the solution with the least possible cost (both implementation-wise and support-wise). But I'm just guessing. 1. http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
