Preview the New Deployments API | Hacker News Reader

Preview the New Deployments API

developer.github.com

74 pointsjoeyespo13 comments

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.

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.

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

I'm excited about this, and was hoping to see more comments here about how this may impact certain aspects of existing deployment processes.

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 :)

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.

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.

This doesn't interact with your server at all.

Look into Fabric for scripting your remote SSH commands.

http://fabfile.org

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

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

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)

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.

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

Reply on news.ycombinator.com