CODEWITHSUNDEEP
testingworkflowproductionrollout
Chris
Chris

Reputation: 1008

Git workflow with a testing server

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

Upvotes: 0

Views: 2034

Answers (4)

tripleee
tripleee

Reputation: 189908

I have a situation where I am developing a tool for handling sensitive data. That means that my development environment only has static tests, and I need to deploy to an isolated server which does not have access to the regular production Git.

What I ended up doing, which I'm not entirely happy with, is set up a test instance of the processing script on the production server, and deploy frequently to that during development.

Previously, we were using Subversion, and I had Darcs set up on top of that, which worked nicely. Edit, commit to Darcs, push to testing, lather rinse repeat, commit to SVN, push to production.

Git tends to get mixed up a lot more than Darcs, but I have gotten this working reasonably by observing that I can have a live Git repository in the testing instance, and that I just need to briefly switch it to a different branch in order to be able to push.

#!/bin/sh

set -e

branch=${1-dev}

# Temporarily switch to a different branch so that pushing is safe
ssh server 'cd project &&
        { git branch -d trash 2>/dev/null || true
            git checkout -b trash; }'

git push server:project "$branch"

# Switch to the newly pushed
ssh server "cd project && git checkout $branch"

With Darcs, I was able to make edits on the testing server and pull them back, but with Git, it's looking to me like I will need to abstain from doing that.

Upvotes: 0

Schwern
Schwern

Reputation: 165546

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.

Upvotes: 1

cjs
cjs

Reputation: 27291

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?"

Upvotes: 2

bluebrother
bluebrother

Reputation: 8906

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.

Upvotes: 0

Related Questions