5 ms·

Preview the New Deployments API

74 points by joeyespo 13y ago

fideloper 13y ago
No one else is excited by this? Are they on their way to having similar functionality as Beanstalkapp (re: ssh/sftp deployments)? The idea definitely has large revenue potential. [Edit] They do say they want you to use your own tooling, but I'm wondering if it's an avenue for future growth.
- danso 13y ago
  I'm excited about this, and was hoping to see more comments here about how this may impact certain aspects of existing deployment processes.
- stephenr 13y ago
  FYI the deployments part of beanstalk is available on its own for use with GitHub, bit bucket, etc. http://dploy.io http://dploy.io
jluxenberg 13y ago
Seems a bit like a more tailored version of a workflow service e.g. http://aws.amazon.com/swf/ http://aws.amazon.com/swf/
tcdent 13y ago
Seems like it would be logical to link this with Issues/Commits to keep track of what was deployed and when. QA interacting via Issues can confirm or deny an 'success'. As a developer, most of my interaction with a bug tracker is responding to a ticket to notify the creator that the change has been deployed.
morganherlocker 13y ago
Love this idea. For small apps, I often just do a git push, ssh to server, git pull, restart app. It sounds like this might make this flow even more simple.
- tcdent 13y ago
  This doesn't interact with your server at all. Look into Fabric for scripting your remote SSH commands. http://fabfile.org http://fabfile.org
  - ivanca 13y ago
    ...It actually interacts with your server; that's pretty much the main thing it does, being the server the "third-party service". Deployments are a request for a specific ref(branch,sha,tag) to be deployed. GitHub then dispatches deployment events that external services can listen for and act on. http://developer.github.com/v3/repos/deployments/ http://developer.github.com/v3/repos/deployments/
    - deleted 13y ago
      [deleted]
    - tcdent 13y ago
      > Keep in mind that GitHub is never actually accessing your servers. It’s up to your 3rd party integration to interact with deployment events. A paragraph or two down the page you linked.
      - deleted 13y ago
        [deleted]
      - ivanca 13y ago
        Yeah, but that's the important bit. After that you (probably) just need a few lines of code: import git import fs handle = fs.open('config.php', 'w+') config = handle.read() git.start('./') git.auth('rsa_pub') git.clone('git@github.com:foo/bar.git') git.remove_untracked() handle.write('config.php', config)
- mkaito 13y ago
  I've had git hooks do this for me for years. I have my hook check for pushes to a branch called "production", export the code (git archive | tar), run some unit tests, and then do whatever it takes to get the code to its destination and restart what needs to be restarted.
josegonzalez 13y ago
This is a welcome change. We've - SeatGeek - been using git tags to mark successful deploys, as well as manual hipchat notifications for deploy starts/successes/failures. It falls over when you do thousands of deploys a year - rarely is there a day when there are absolutely no deploys - as we do. Any clones of git repos simply fall over with so many tags. Cleaning those up on the servers is also annoying. One thing I'll be curious to see is if there is a way to mark partial deploys. For certain services, SeatGeek deploys to multiple datacenters in distinct deployments (not rolling). These are tracked separately, though it would be nice to have them in a single deployment. Looks like it'll require extra metadata in the `description` field. One minor annoyance is our increased dependence upon Github :)
- falsedan 13y ago
  For those partial deployments, sounds like you're after a release tool, where 'release' is used in the Amazon sense: a versioned collection of versioned packages. Doesn't fix your tags problem... Octopus Deploy has nailed releases, but is still Windows-only.

74 points by joeyespo 13y ago

No one else is excited by this? Are they on their way to having similar functionality as Beanstalkapp (re: ssh/sftp deployments)? The idea definitely has large revenue potential. [Edit] They do say they want you to use your own tooling, but I'm wondering if it's an avenue for future growth.

danso 13y ago
I'm excited about this, and was hoping to see more comments here about how this may impact certain aspects of existing deployment processes.
stephenr 13y ago
FYI the deployments part of beanstalk is available on its own for use with GitHub, bit bucket, etc. http://dploy.io http://dploy.io

jluxenberg 13y ago

Seems a bit like a more tailored version of a workflow service e.g. http://aws.amazon.com/swf/ http://aws.amazon.com/swf/

tcdent 13y ago

Seems like it would be logical to link this with Issues/Commits to keep track of what was deployed and when. QA interacting via Issues can confirm or deny an 'success'. As a developer, most of my interaction with a bug tracker is responding to a ticket to notify the creator that the change has been deployed.

morganherlocker 13y ago

Love this idea. For small apps, I often just do a git push, ssh to server, git pull, restart app. It sounds like this might make this flow even more simple.

tcdent 13y ago
This doesn't interact with your server at all. Look into Fabric for scripting your remote SSH commands. http://fabfile.org http://fabfile.org
- ivanca 13y ago
  ...It actually interacts with your server; that's pretty much the main thing it does, being the server the "third-party service". Deployments are a request for a specific ref(branch,sha,tag) to be deployed. GitHub then dispatches deployment events that external services can listen for and act on. http://developer.github.com/v3/repos/deployments/ http://developer.github.com/v3/repos/deployments/
  - deleted 13y ago
    [deleted]
  - tcdent 13y ago
    > Keep in mind that GitHub is never actually accessing your servers. It’s up to your 3rd party integration to interact with deployment events. A paragraph or two down the page you linked.
    - deleted 13y ago
      [deleted]
    - ivanca 13y ago
      Yeah, but that's the important bit. After that you (probably) just need a few lines of code: import git import fs handle = fs.open('config.php', 'w+') config = handle.read() git.start('./') git.auth('rsa_pub') git.clone('git@github.com:foo/bar.git') git.remove_untracked() handle.write('config.php', config)
mkaito 13y ago
I've had git hooks do this for me for years. I have my hook check for pushes to a branch called "production", export the code (git archive | tar), run some unit tests, and then do whatever it takes to get the code to its destination and restart what needs to be restarted.

josegonzalez 13y ago

This is a welcome change. We've - SeatGeek - been using git tags to mark successful deploys, as well as manual hipchat notifications for deploy starts/successes/failures. It falls over when you do thousands of deploys a year - rarely is there a day when there are absolutely no deploys - as we do. Any clones of git repos simply fall over with so many tags. Cleaning those up on the servers is also annoying. One thing I'll be curious to see is if there is a way to mark partial deploys. For certain services, SeatGeek deploys to multiple datacenters in distinct deployments (not rolling). These are tracked separately, though it would be nice to have them in a single deployment. Looks like it'll require extra metadata in the `description` field. One minor annoyance is our increased dependence upon Github :)

falsedan 13y ago
For those partial deployments, sounds like you're after a release tool, where 'release' is used in the Amazon sense: a versioned collection of versioned packages. Doesn't fix your tags problem... Octopus Deploy has nailed releases, but is still Windows-only.