[andyhmltn]

Depends on whether or not I'm actively working on a new part of the site. It varies from 10+ times to 1-2 times an hour.

However, with all these people talking about deployment, I just wanna hijack (sorry!) and ask if anybody can help with my current deployment setup:

- Branch into a new feature (refactor-javascript for example) - Commit constantly - Rebase with master then merge into master - Push to remote repo - SSH to server, and then pull from the same repo - (.git isn't exposed via HTTP)

What's the better way of doing this? If you could help that'd be great :-) Drop me an email at [e-mail]

[shawabawa3]

> Push to remote repo - SSH to server, and then pull from the same repo

I have a server setup with a headless git repo and non-headless one. When I push to the headless repo, the post-receive hook goes to the other repo, pulls from the headless, runs tests and restarts the server

So to deploy I just do

    git push deploy master

And get instant feedback that all the tests passed and server was restarted

[andyhmltn]

That's kind of what I do at the moment but I ended up just ditching the hook as it's not usually needed. I use a headless repo on the server that is then pulled into the live folder.

I always found that the hook never really worked for some bizarre reason. Even something as simple as:

cd /home/deployer/wordpress/wp-content/themes/my-theme && git pull origin master

failed.

[shawabawa3]

Strange, it might be to do with GIT_WORK_TREE and GIT_DIR being set (they are set automatically in hooks I think).

My hook is:

    cd $REPO_DIR
    
    unset GIT_DIR
    unset GIT_WORK_TREE
    
    git checkout deploy && \
    git stash && \
    git pull

[andyhmltn]

I'll reply here again: Thanks for that! I'll check it out now

[hannesfostie]

We never rebase like that, and instead use git merge master --no-ff

We also never SSH into a server, and instead use Capistrano to handle this for us. Capistrano works great with Rails, but even other frameworks have plugins to handle this. And if you're new to capistrano, take a look at http://capo.io (shameless plug: we built this) for readily available recipes for all kinds of tasks. We use Capo for all our projects, ranging from static sites to jekyll to sinatra, rack and rails apps.

[andyhmltn]

I love capistrano! Sadly, most of the deployment happens on a wordpress theme at the moment.

[bendavis381]

Have a look at Fabric (http://docs.fabfile.org/en/1.6/)

I wrote a quick fabfile yesterday that automatically commits/merges my local changes, pushes to a private GitHub repo, then SSHs into my production server, pulls down the latest code and restarts the web server. Gives me feedback along the way too.

[StavrosK]

No, don't look at fabric! Fabric is good for some stuff, but deployments should be repeatable, automated and idempotent. Look at ansible.cc instead.

Don't use fabric for deployment (even though it's a fantastic tool for many use cases).

[mbeattie]

I don't understand... how is that a knock on fabric? I have software built into packages and then config templates and some key/value stuff to substitute in. My fabric scripts log in, install a package, put the generated config files, and then restart the server. I can run this over and over again (repeatable) with one command (automated) and it always ends up at the same current version (idempotent).

[StavrosK]

It's not a knock on fabric, the same way using a hammer on screws isn't a knock on hammers. It works sometimes, but you generally want to use the right tool for the job.

[pcowans]

This doesn't seem that bad to me, what problems is it causing?

The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.

[andyhmltn]

It isn't causing any problems! But in a recent thread on git deployment, there was a tonne of hate for this method

[pcowans]

... one other thing though. With a bit of practice you can remove the need to develop on feature branches; break things down into really small chunks and get into the habit of making half-done features unobtrusive (e.g. hiding UI elements until they're ready). That way you can push to master often and have confidence it'll always be safe to deploy, which simplifies your tooling and reduces the scope for merge conflicts etc.

[andyhmltn]

I personally find branching a lot better than the method you described. Master is always safe to deploy in my current setup and I don't usually get merge conflicts :-)

[pcowans]

Don't worry about it then - there are more important things to spend your time doing.

[CiaranR]

Check out

https://github.com/capistrano/capistrano

and

http://rubygems.org/gems/fabric