I mostly work with java, so the build server is doing a clean compilation, to ensure the code word outside my dev environment. Pulling in known versions of dependencies, some packaging, unit and integration tests etc. Mostly using Maven.

Whilst some of that is somewhat specific to java, I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. And I'd still want to run at least some integration tests, even for the simplest project.

And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway.

Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production.

In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

> And I'd still want to run at least some integration tests, even for the simplest project.

Integration tests run on the dev or CI server, in my case.

> And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway.

The code servers aren't in the internal network, in my case. They're already internet-facing, since I need to pull from them.

> Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

In my case, if my code isn't on the server, the server doesn't run. There's no need to set up .htaccess, since the HTTP server doesn't serve anything off the filesystem.

>> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. >In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

The problem is not that dev dependencies exist, the problem is that they might be undeclared or unrecorded. I have imagemagic on my dev machine, but if it isn't installed as part of the server setup script, then it won't be on the production server. The tests might run fine on a dev server that happens to have imagemagic on it, but fail in production.

>Integration tests run on the dev

If you run your integration tests in your dev environment, you might not catch some on the fly configuration changes or utility installations - undeclared dependencies.

I'm using "dev environment" and "dev server" distinctly. The dev environment is whatever I have on my computer, the dev server is a server that mirrors production. If there's a dependency on your dev environment that isn't on production, you'll catch it when you deploy to one of the dev servers. Same with the integration tests.

Suppose you've invested in a build server anyway, for CI.

Then you can just add/extend a job to create a release package, and deploy it.

Doesn't take that much effort, and lets you avoid infecting your production boxes with dev infrastructure/scaffolding, as `NickNameNick` suggests.

What sort of def scaffolding do you mean? The benefits of just pulling the repo are that you can use ansible-pull to automatically update the servers whenever new code is merged to master, which would be more complicated if you had the CI server doing the pushing.

> What sort of def scaffolding do you mean?

version control software, to start with. perhaps more.

i guess my viewpoint is coloured as the last thing i was working on was deployed to client desktop machines. there was absolutely no way we were going to be pushing to those with version control.

if you are deploying to a server you own, i guess in principle you can do whatever you want. one of my colleagues rigged a build to create a debian package for the server-side version of the code we worked on. that took a bit of mucking about to get going but was very nice when it was set up.

Building a deb is also an option, I generally don't prefer it because just pulling is easier to set up, and debs don't have that many advantages when you're dealing with interpreted server code.

Set up a virtualenv with defined versions of all dependencies, on install the python code there. And tar up the virtualenv.

Or create a .deb or .rpm package out of the python code.

In a non-trivial setup, just doing a 'git checkout' isn't enough for a deployment.

I'll just point out that your assumption that I'm only doing a "git checkout" is completely unwarranted.

Given that in the comment to which that was a reply, you opined that 'It doesn't seem like setting up a build server just to do "git checkout; rm .git" is worth the effort.', it's not completely unwarranted.

The part that the build server can handle is the "git checkout" part, maybe create a virtualenv with the dependencies. In that case, doing a "git checkout" is enough for deployment, because you're already assuming that the rest of the deployment happens elsewhere.

If you're working with Python, you can create builds of individual modules via zip archives. This lets you create a versionable, signable build artifact which can be easily deployed almost everywhere. They can even include static versions of you dependencies, making the deploy less reliant on what is installed on the target server.

A great tool for this is pex: https://github.com/pantsbuild/pex