
Deployer – A Deployment Tool for PHP - nikolay
http://deployer.org/
======
ericcholis
[http://www.deploybot.com](http://www.deploybot.com) is pretty good as well,
platform and language agnositc.

~~~
manyxcxi
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.

------
nodesocket
Shameless plug: Founder of [https://commando.io](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.

~~~
billmalarky
Are you guys still Digital Ocean only or generic?

~~~
nodesocket
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)

~~~
billmalarky
Good to know, thanks.

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

~~~
leftnode
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.

~~~
mikey_p
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.

------
craigmcnamara
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.

~~~
smt88
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.

~~~
craigmcnamara
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.

~~~
manyxcxi
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.

~~~
craigmcnamara
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.

------
user4096
If you're at work, don't type in tit in that console. :D

------
malas
Anyone wants to bake a proper full tutorial on how to use it? Current
documentation looks almost like auto generated from code comments..

~~~
seanwilson
There's not that much to learn fortunately. The getting started guide should
be enough:

[http://deployer.org/docs](http://deployer.org/docs)

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

