Preview the New Deployments API

http://developer.github.com/changes/2014-01-09-preview-the-new-deployments-api/

by joeyespo • 13 years ago

74 13 13 years ago

developer.github.com

fideloper• 13 years 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• 13 years 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• 13 years ago

FYI the deployments part of beanstalk is available on its own for use with GitHub, bit bucket, etc. http://dploy.io

jluxenberg• 13 years ago

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

tcdent3• 13 years 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• 13 years 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.

tcdent3• 13 years ago

This doesn't interact with your server at all.

Look into Fabric for scripting your remote SSH commands.

http://fabfile.org

ivanca2• 13 years 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/

mkaito• 13 years 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• 13 years 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• 13 years 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.

Preview the New Deployments API

Related Stories