Git workflow with a testing server

Question

Hi,

I'm using git for my workflow and I have a remote testing server. What would be the best way to do this.

Currently I make my changes on my workstation and I commit changes and then push to server. But this would quickly lead to many small commits. I want to avoid setting up testing server on my workstation.

And rebasing commits is not okay cause I push to a bare repository (which then has a hook that pulls that to a working directory that is the testing server) that is accessible by others.

Thanks

Answer 1

Why can't you make small commits on a development branch, then squash them into a single commit that gets merged back to the main branch which gets pushed to the server? I'm frequently using private development branches.

Answer 2

I think that the real problem here is that you want to "avoid setting up testing server on [your] workstation."

A key philosophy in QAM is that every host can be as much like the production system as possible, so that we minimize the amount of work to be done to move from development to testing to production.

Deployment is not a trivial process, and the more your developers have to deal with it, the easier it will be to get the application (and the inevitable updates thereof) rolled out.

So you really should be thinking, "how closely can I replicate the production environment on my development machine?"

Answer 3

There's nothing wrong with small commits. In fact, they're preferable as they're easier to review than a big blob patch. They better show your thought process and allow the work to be reviewed in small chunks. And a reviewer can always turn a lot of small commits into one big one, but the reverse cannot be done. This assumes your commits are in the form of logical chunks.

But since you're not testing until after you push I'd guess that your commits are more of the form of "oops, I broke something last commit". Those are no good and will hinder review. Ideally they should be --amended to the previous commit.

Code, commit, then test hinders TDD. What you want to do is start from a known good state, code, run the tests, see a failure and then know it was caused by something in your very small and easy to debug diff.

It also means you're pushing broken changes into master which will screw everyone else on the team up.

So yes, you need a test environment on your dev machine. Something which runs at the push of a button and completes quickly (we're talking minutes, tops). Should the full suite prove too slow or cumbersome you can run just part of the suite, perhaps the part you feel is most relevant to your change, and then let the test server run the full suite after you push. This is a good compromise between test efficiency and thoroughness.

If for some reason you can't get a test environment running on your dev machine, you can work in your own branch and push that to test. Then if it doesn't work you can --amend your fix. Once you're done with your feature you can merge your changes into master. This both eliminates "oops, I broke it" commits and keeps you from breaking master for everyone else while still making small, easy to review commits.

What you should be using your testing server for is to run the tests in as close a simulation of production as possible, developer machines are often heterogeneous and that's healthy, and to automate running the tests in case someone gets sloppy.