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

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.

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.

Reply via email to