back
26 comments
http://www.deploybot.com is pretty good as well, platform and language agnositc.
We use DeployBot for a whole host of different projects and I love it. EC2, ElasticBeanstalk, and DigitalOcean deployments with everything from Worspress, Java, Node, and Laravel projects. It's really nice how flexible it has been. Also auto deploy from GitHub or BitBucket on commit is nice for development environments.

The only issue that I have is that it seems like our little secret has gotten out and they've become more popular and things are starting to slow down- certain sections of the interface have been getting very slow on the occasion I need to look at something.

Shameless plug: Founder of https://commando.io here. Commando.io is a web based ssh interface to multiplex commands to servers, great for deployments. You can trigger commands via our web interface, API, GitHub integration (git push... run commands on severs), and even IOS mobile app.

Hopefully useful for others reading this thread.

Wait, so, this logs in for me to run commands on my servers? It doesn't look like it's self-hostable though?

Sorry, but I feel like I'm missing something? this seems terribly insecure.

Nah it's fine, just excuse me while I smash this basket full of eggs.

Not sure what the use case is either since you can already send multiple commands manually (and of course automatically) with Ansible, it's almost comically easy to setup as well.

Are you guys still Digital Ocean only or generic?
If it has sshd it should work, so any provider, even co-location. We just integrate with DigitalOcean, AWS, Rackspace, and Linode (allow you to import severs and tags)
Good to know, thanks.
Nice, looks very similar to Capistrano, but sometimes it's nice to stick with PHP if you're already using it.

The only problem I have with tools like this (and Capistrano) with most modern projects, is that there are usually a number of build steps related to getting production code in place, whether composer dependencies, or CSS/JS compilation, etc. With these tools, it's kinda hard to figure out how to implement this stuff, since they essentially just do a Git checkout on each server, and then run commands on each one. I kinda hate the idea of having tools to compile CSS/JS on each web server, and then each server running it's compilation separately. Has anyone come up with a clean way to separate these tasks from the task of deploying?

Have an intermediate build server like Jenkins or Bamboo that does all of that for you, packages everything up into a single deployable artifact (tarball, .deb, or RPM for example) and then deploy that out to each of your servers.
That's what I do for larger clients or projects, it's just a bummer, that smaller projects need that level of integration to follow best practices these days.
We just do all that compilation prior to check-in for release branch. Basically, version control holds the compiled 'snapshot' of a working app, and host specific variances in the code is forbidden. (composer is for project bootstrapping rather than a 'build step') -btw, we do this with subversion since git doesn't handle large repos well +empty directories.
Quantify "git doesn't handle large repos". Large in discrete size or file count?
So it's a weak copy of Capistrano 2, but 10 years late and written in PHP? I'm confused, what is the benefit of copying an established software package. You'd be better served using the Capistrano 3 for complicated deploys and Mina for simple deploys. PHP is an awful language to write a DSL and in my opinion just plain awful to use. I prefer to write Ruby, but I don't rewrite every system I depend on in Ruby.

For the record I'm maintaining a site written in PHP and I dislike PHP for real reasons(poor tooling, poor REPL, poor standard library, poor syntax) not just because it's not the language I've used the most.

PHP actually has great tooling now (PhpStorm + Xdebug). The standard library is also fantastic in terms of its breath -- almost everything is already baked into PHP. It's really inconsistent, though, which could be enough reason for someone to call it "poor".

The syntax... I dunno. I think that's strongly a matter of personal preference. I just wanted to point out that PHP can be less painful than people realize (although still painful).

Edit: also be sure to look into Airbrake for logging exception in production. I find it to be pretty indispensable.

The project I mentioned is a legacy codebase that needs lots of work to even get it to consistently raise exceptions. Many places things happen trigger_error is used, which is not caught by Honeybadger(basically the same as Airbrake) and configuring the code to raise Exceptions for errors leads to bad behavior because previous programmers used trigger_error as a debug mechanism as well. Also there are no tests, so there is no good starting point to correct the transgressions that many PHP programmers don't regard as problematic at all. It's the embodiment of everything wrong with PHP and correcting the abuses is an enormous effort.

I just looked at xdebug, it can't even come close to the Eclipse debugger for Java or Pry for Ruby.

I just get sad every time I see a new large investment in PHP because I've never had a positive experience using it compared to another language and I strongly believe that you can't polish a turd.

If you're just now looking into xdebug, how could you know the differences or make a valid comparison? For one, you can remote debug way easier than with JVM debuggers. For the 80% use case it is just as easy/just as useful. The JVM debugging tools provide way more functionality and for local debugging are just there and ready to use in a way xdebug isn't. But frankly, the fact that you're JUST looking into xdebug makes me question whether or not people should be paying you to write PHP.

I have kids fresh out of college that work for me that use xdebug all day every day, remote, over Vagrant VMs, and local with different IDEs. This is a solved issue- you clearly are working in a smelly codebase, don't have the 'advanced' PHP skills you think you do, and seem to think that PHP is awful because the other cool kids said so.

PHP isn't just bad tooling, it's a bad attitude, like your attitude. I've said that I dislike the PHP experience for many valid reason and you question my competence, experience and validity of my experiences with PHP. I looked in to XDebug and it's not the kind of tool I was looking for. It's heavy weight, requires changing the VM config and from the cached version of the website that is down at the moment appears to imply that it's best used within an IDE.

I'd like a REPL debugger that I can activate easily and use from my terminal without fucking with the VM too much. My real goal is to not have to make changes to this project beyond correcting damage inflicted by the PHP attitude of blissful incompetence and copy paste. While I do believe that you can write good code or bad code in any language, PHP does not in any way help it's practitioners to write good code and as PHP users poorly copy my favorite things from my other favorite languages they always miss the mark and loudly complain when the shortcomings are pointed out.

I've wasted far too much time responding to you, so you just keep smearing digital shit on the walls, I have code to ship.

I feel your pain. I make a lot of my money maintaining legacy PHP projects, but I'm hoping to entirely get away from PHP in 2016.

It's incredibly difficult to fight the "just rewrite it in [some better language]!" reaction whenever I first look at a code base like the one you're describing.

> trigger_error as a debug mechanism as well

Yeah... unfortunately that sounds very familiar. "Abuses" is a good word for it.

At least with Xdebug, you can use breakpoints instead of "var_dump($whatever); exit;" and you can navigate through your stack trace. No, definitely not as good as Java tooling, though.

Just because you've come across a shit code base doesn't make PHP an awful language. I've come across many more terrible Ruby projects than I have PHP. The fact that you think Ruby had better tooling and support than PHP, the most popular language on the web, shows your ignorance of the language.

I agree with your leading sentiment that this project is currently too little/too late for me and my deployment automation needs, but frankly, you obviously don't know a damn thing about the ecosystem.

I've worked in C++, Java, Ruby and PHP. I'm aware of what PHP has to offer and compared to the tooling in other languages PHP is anemic at best and a fractal of bad design at worst.

You're getting very tribal and Ad-hominem in your attacks because I don't share any affection for PHP and consider the whole language to be a mistake. Since PHP 5.3 things have been moving in the right direction, but it's too little too late as a language. As for tooling everything is a half assed copy of something from the Ruby ecosystem. If you have some tips for tools comparable to Pry in Ruby or any practical REPL or and interactive debugger comparable to VisualStudio or Eclipse please by all means share, but keep your worthless snipes to yourself.

I consistently find myself frustrated when working in PHP not because I've not mastered it, but because all of the other languages I've mentioned have a better developer experiences, better tooling and consistent APIs. PHP in my experience has none of these and your response and not changed my thoughts.

If you're at work, don't type in tit in that console. :D
Anyone wants to bake a proper full tutorial on how to use it? Current documentation looks almost like auto generated from code comments..
There's not that much to learn fortunately. The getting started guide should be enough:

http://deployer.org/docs

I found it quite easy to set up actually.

Just use one of the pre-existing recipes as a starting point, take common.php out and have a look.

Let me know if you need any specific help.

We use it for production deployment to more than 100+ servers. Really fast.