
Preview the New Deployments API - joeyespo
http://developer.github.com/changes/2014-01-09-preview-the-new-deployments-api/
======
tcdent
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.

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

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

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

------
morganherlocker
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
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
...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/)

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

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

------
jluxenberg
Seems a bit like a more tailored version of a workflow service e.g.
[http://aws.amazon.com/swf/](http://aws.amazon.com/swf/)

