8 ms·

Deployer – A Deployment Tool for PHP

46 points by nikolay 11y ago

malas 11y ago
Anyone wants to bake a proper full tutorial on how to use it? Current documentation looks almost like auto generated from code comments..
- seanwilson 11y ago
  There's not that much to learn fortunately. The getting started guide should be enough: http://deployer.org/docs http://deployer.org/docs
- kyriakos 11y ago
  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.
nodesocket 11y ago
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 11y ago
  Are you guys still Digital Ocean only or generic?
  - nodesocket 11y ago
    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 11y ago
      Good to know, thanks.
  - deleted 11y ago
    [deleted]
- CaptSpify 11y ago
  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.
  - noir_lord 11y ago
    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.
mikey_p 11y ago
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 11y ago
  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 11y ago
    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.
- junker101 11y ago
  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.
  - crasco 11y ago
    Quantify "git doesn't handle large repos". Large in discrete size or file count?
ericcholis 11y ago
http://www.deploybot.com http://www.deploybot.com is pretty good as well, platform and language agnositc.
- manyxcxi 11y ago
  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.
user4096 11y ago
If you're at work, don't type in tit in that console. :D
craigmcnamara 11y ago
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 11y ago
  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 11y ago
    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.
medv 11y ago
We use it for production deployment to more than 100+ servers. Really fast.

46 points by nikolay 11y ago

malas 11y ago

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

seanwilson 11y ago
There's not that much to learn fortunately. The getting started guide should be enough: http://deployer.org/docs http://deployer.org/docs
kyriakos 11y ago
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.

nodesocket 11y ago

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 11y ago
Are you guys still Digital Ocean only or generic?
- nodesocket 11y ago
  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 11y ago
    Good to know, thanks.
- deleted 11y ago
  [deleted]
CaptSpify 11y ago
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.
- noir_lord 11y ago
  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.

mikey_p 11y ago

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 11y ago
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 11y ago
  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.
junker101 11y ago
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.
- crasco 11y ago
  Quantify "git doesn't handle large repos". Large in discrete size or file count?

ericcholis 11y ago

http://www.deploybot.com http://www.deploybot.com is pretty good as well, platform and language agnositc.

manyxcxi 11y ago
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.

user4096 11y ago

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

craigmcnamara 11y ago

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 11y ago
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 11y ago
  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.

medv 11y ago

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