6 ms·

Show HN: Deploydo – Deployment made easy

46 points by _query 12y ago

matejkramny 12y ago
Why not just use ansible?
recursive 12y ago
There's a lot of explanations of source code deployments, but it never mentions compiled binaries. Is it capable deploying build outputs?
- _query 12y ago
  It would be possible to deploy your binaries but in this case you have to rebuild the whole project on each server. If you have long build times, deploydo is not the right tool for the job.
zzzzz_ 12y ago
"shinny" should be "shiny" on this line: We will do the rest for you. Just look on our shinny loading indicators while we are deploying your code without any downtime!
- _query 12y ago
  Thanks for pointing this out, just fixed this.
  - submersible 12y ago
    Also: Start using deploydo in 5 minutes, completly [sic] free!
    - _query 12y ago
      Thanks, fixed.
frozenkill 12y ago
> Ever asked yourself why deploying your projects to your servers is such a pain? Personally, no. I haven't heard it from my peers either. I just use rsync and quick scripts; others use PaaS (self-hosted or managed) that generally handles deployment pretty neatly. The only place I've heard complaints about deployment is inside of large multi-tier organizations, where the problem boiled down to communication issues between dev and ops, not tooling. I suspect I'm supposed to be the target audience here, but I'm not sure what problem this solves for me. On a first impression this looks mostly like a way to lock myself into a workflow that leaves a lot of unanswered questions (re: server security, platforms/frameworks supported, etc), with very marginal benefits.
- _query 12y ago
  > I just use rsync and quick scripts How do you handle zero-downtime deployments with rsync? Also what about rollbacks, how do you handle these? In case you have team of a few people, how do you know what already got deployed? How do you know if anyone is deploying just at the moment when you are deploying something? We wanted to solve these questions with our tool. In case you haven't had these problems yourself, I think you aren't our target audience as you pointed out :)
drsintoma 12y ago
It is really worth having a .do domain? given that they are fairly expensive and seems like google will treat them as specific from Dominican Republic and not generic[1]? [1]https://support.google.com/webmasters/answer/1347922?hl=en https://support.google.com/webmasters/answer/1347922?hl=en
vanilla 12y ago
>You just provide us login credentials to [your] server ...
- sergiotapia 12y ago
  This type of comment is now highly discouraged on Show HN posts. Please post only constructive negative comments, or if you don't have any - rather choose to not comment at all.
druiid 12y ago
The idea of these hosted deployment systems always scares me. Essentially you have no choice but to open SSH to the universe. This is far beyond best practices for at least a couple reason. The first would be that if at all possible you should be hiding SSH behind a VPN so that casual or not so casual attempts at breaking in to the server are made that much more difficult (this makes even people somehow getting a stolen private key a non-issue). The second would be that giving an 'unknown' third-party this kind of access to your systems leaves you open to them being exploited and then exploiting you (and this scenario seems much more likely than someone guessing your password if you are using one on SSH for some reason). All in all, deployment seems like something to me which I'd always want to keep in-house.
- tdumitrescu 12y ago
  Would be a nice tool if you could host it yourself though.
  - wereHamster 12y ago
    I was recently facing the decision whether to deploy from codeship.io directly or not. In the end it turned out not possible due to technical reasons. So I repurposed my old CI server and turned it into a 'continuous deployment' server which integrates well into github. You can easily run it on your own system, it's just one (almost static) binary. https://caurea.org/2014/07/01/mudbath-is-now-a-continuous-deployment-server.html https://caurea.org/2014/07/01/mudbath-is-now-a-continuous-de...
- benatkin 12y ago
  I'm comfortable with having a company I trust enough handling deployment. In order to trust them I have to see them do difficult things well and it probably needs to be more than just a couple people. A small deployment service like this will probably remain in the area where I don't know enough about them to trust them. This is why I turn to Continuous Integration tools (CircleCI) or Project Hosts (Beanstalk, Springloops) for deployment. By observing them doing complicated things I get the feeling that they know what they're doing. Perhaps OP should think bigger.
nathan_f77 12y ago
Yes, I want to use a web interface like this, and the config management feature is something that I would find very useful. No, I'm not comfortable giving a third-party service SSH access to our servers. Besides, all of our machines are on a private network behind a VPN. This is a best practice that most, if not all, companies should follow.
- _query 12y ago
  We can understand your point. You have to trust us like you have to trust your server hosting provider.
ksikka 12y ago
Web UI vs SSH is hardly the problem. More often, it's setting the environment set up on the remote server that's a terrible pain, then you have to set up domains and ssl and all that nonsense. TL;DR configuration is pain to do manually every time, I hope you can make it go away. If you have ideas, comment below.
- _query 12y ago
  It's not only the ui. The reason why we build deploydo is that we needed to have a transparent deployment process which can scale up to 30 servers. We wanted to be able to see what was deployed to which servers and when. Just like your github newsfeed. Another goal we wanted to archive is confidence: We wanted a process where we can clearly see everything which will be changed on the server, therefore we implemented line-by-line diffs between the server and the repository. These things were the real pain in our process.
  - ksikka 12y ago
    I see. How are you different from these services?: http://dploy.io/ http://dploy.io/ http://beanstalkapp.com/features/deployments http://beanstalkapp.com/features/deployments I'm not trying to attack you or anything, just trying to understand how the product fills an unmet need.
    - _query 12y ago
      Thanks for asking this, it's a valid question. We differ from dploy.io in the following points: - we provide true line-by-line diffs between the remote server and the deployed code, other deployment platforms only provide diffs by running `git diff`. This will help you to see if some files got edited on the remote server, e.g. for applying a hot fix. - we only deploy files that have really changed, therefore we save traffic if you have big project - we are faster (see http://t.co/IQM85FTa1D http://t.co/IQM85FTa1D) - our deployment process uses symlinks to avoid any downtime. Therefore we can also rollback very very fast. Other deployment providers don't use symlinks and upload files one by one, therefore leading your application to an unstable state because file A got already updated but file B is not yet on the newest version. - we are very stable. If something goes wrong during the deployment your users won't be affected because we only update the symlink at the end of our process, and only if everything before exited without errors (exit code == 0)
gingerlime 12y ago
from the features page: > You can deploy nearly any programming language with our tool that works by just transferring the files Maybe I misunderstand something, but this sounds like it trivializes the complexities of a typical deployment process. Services need to be restarted, code updated, database migrations run and so on... I think for it to be successful you need to figure out a way to make automating those fragile deployment steps easy (and solid). This is a problem lots of configuration management tools are trying to solve (chef, puppet, ansible, fabric, capistrano etc). Or at least help integrate deploy.do with such tools.
- _query 12y ago
  We provide hooks in our deployment process which you can use to do these kind of tasks. E.g. if you have to restart your web server after your deployment you will typically add something like `sudo service httpd restart` into the hook. If you have a really complex deployment process and need more than just our hooks we are not the right tool for solving your problem. But for your typically php or rails application you will be happy with deploydo :)
iancarroll 12y ago
This is difficult for some setups, as it relies on an open SSH port. Our AWS instances are not publicly accessible, so this makes it hard.
bowlofpetunias 12y ago
"Ever asked yourself why deploying your projects to your servers is such a pain?" I know exactly why it's such a pain. Because every deployment tool available only deals with the easy parts.

46 points by _query 12y ago

Why not just use ansible?

There's a lot of explanations of source code deployments, but it never mentions compiled binaries. Is it capable deploying build outputs?

_query 12y ago
It would be possible to deploy your binaries but in this case you have to rebuild the whole project on each server. If you have long build times, deploydo is not the right tool for the job.

zzzzz_ 12y ago

"shinny" should be "shiny" on this line: We will do the rest for you. Just look on our shinny loading indicators while we are deploying your code without any downtime!

_query 12y ago
Thanks for pointing this out, just fixed this.
- submersible 12y ago
  Also: Start using deploydo in 5 minutes, completly [sic] free!
  - _query 12y ago
    Thanks, fixed.

frozenkill 12y ago

> Ever asked yourself why deploying your projects to your servers is such a pain? Personally, no. I haven't heard it from my peers either. I just use rsync and quick scripts; others use PaaS (self-hosted or managed) that generally handles deployment pretty neatly. The only place I've heard complaints about deployment is inside of large multi-tier organizations, where the problem boiled down to communication issues between dev and ops, not tooling. I suspect I'm supposed to be the target audience here, but I'm not sure what problem this solves for me. On a first impression this looks mostly like a way to lock myself into a workflow that leaves a lot of unanswered questions (re: server security, platforms/frameworks supported, etc), with very marginal benefits.

_query 12y ago
> I just use rsync and quick scripts How do you handle zero-downtime deployments with rsync? Also what about rollbacks, how do you handle these? In case you have team of a few people, how do you know what already got deployed? How do you know if anyone is deploying just at the moment when you are deploying something? We wanted to solve these questions with our tool. In case you haven't had these problems yourself, I think you aren't our target audience as you pointed out :)

drsintoma 12y ago

It is really worth having a .do domain? given that they are fairly expensive and seems like google will treat them as specific from Dominican Republic and not generic[1]? [1]https://support.google.com/webmasters/answer/1347922?hl=en https://support.google.com/webmasters/answer/1347922?hl=en

vanilla 12y ago

>You just provide us login credentials to [your] server ...

sergiotapia 12y ago
This type of comment is now highly discouraged on Show HN posts. Please post only constructive negative comments, or if you don't have any - rather choose to not comment at all.

druiid 12y ago

The idea of these hosted deployment systems always scares me. Essentially you have no choice but to open SSH to the universe. This is far beyond best practices for at least a couple reason. The first would be that if at all possible you should be hiding SSH behind a VPN so that casual or not so casual attempts at breaking in to the server are made that much more difficult (this makes even people somehow getting a stolen private key a non-issue). The second would be that giving an 'unknown' third-party this kind of access to your systems leaves you open to them being exploited and then exploiting you (and this scenario seems much more likely than someone guessing your password if you are using one on SSH for some reason). All in all, deployment seems like something to me which I'd always want to keep in-house.

tdumitrescu 12y ago
Would be a nice tool if you could host it yourself though.
- wereHamster 12y ago
  I was recently facing the decision whether to deploy from codeship.io directly or not. In the end it turned out not possible due to technical reasons. So I repurposed my old CI server and turned it into a 'continuous deployment' server which integrates well into github. You can easily run it on your own system, it's just one (almost static) binary. https://caurea.org/2014/07/01/mudbath-is-now-a-continuous-deployment-server.html https://caurea.org/2014/07/01/mudbath-is-now-a-continuous-de...
benatkin 12y ago
I'm comfortable with having a company I trust enough handling deployment. In order to trust them I have to see them do difficult things well and it probably needs to be more than just a couple people. A small deployment service like this will probably remain in the area where I don't know enough about them to trust them. This is why I turn to Continuous Integration tools (CircleCI) or Project Hosts (Beanstalk, Springloops) for deployment. By observing them doing complicated things I get the feeling that they know what they're doing. Perhaps OP should think bigger.

nathan_f77 12y ago

Yes, I want to use a web interface like this, and the config management feature is something that I would find very useful. No, I'm not comfortable giving a third-party service SSH access to our servers. Besides, all of our machines are on a private network behind a VPN. This is a best practice that most, if not all, companies should follow.

_query 12y ago
We can understand your point. You have to trust us like you have to trust your server hosting provider.

ksikka 12y ago

Web UI vs SSH is hardly the problem. More often, it's setting the environment set up on the remote server that's a terrible pain, then you have to set up domains and ssl and all that nonsense. TL;DR configuration is pain to do manually every time, I hope you can make it go away. If you have ideas, comment below.

_query 12y ago
It's not only the ui. The reason why we build deploydo is that we needed to have a transparent deployment process which can scale up to 30 servers. We wanted to be able to see what was deployed to which servers and when. Just like your github newsfeed. Another goal we wanted to archive is confidence: We wanted a process where we can clearly see everything which will be changed on the server, therefore we implemented line-by-line diffs between the server and the repository. These things were the real pain in our process.
- ksikka 12y ago
  I see. How are you different from these services?: http://dploy.io/ http://dploy.io/ http://beanstalkapp.com/features/deployments http://beanstalkapp.com/features/deployments I'm not trying to attack you or anything, just trying to understand how the product fills an unmet need.
  - _query 12y ago
    Thanks for asking this, it's a valid question. We differ from dploy.io in the following points: - we provide true line-by-line diffs between the remote server and the deployed code, other deployment platforms only provide diffs by running `git diff`. This will help you to see if some files got edited on the remote server, e.g. for applying a hot fix. - we only deploy files that have really changed, therefore we save traffic if you have big project - we are faster (see http://t.co/IQM85FTa1D http://t.co/IQM85FTa1D) - our deployment process uses symlinks to avoid any downtime. Therefore we can also rollback very very fast. Other deployment providers don't use symlinks and upload files one by one, therefore leading your application to an unstable state because file A got already updated but file B is not yet on the newest version. - we are very stable. If something goes wrong during the deployment your users won't be affected because we only update the symlink at the end of our process, and only if everything before exited without errors (exit code == 0)

gingerlime 12y ago

from the features page: > You can deploy nearly any programming language with our tool that works by just transferring the files Maybe I misunderstand something, but this sounds like it trivializes the complexities of a typical deployment process. Services need to be restarted, code updated, database migrations run and so on... I think for it to be successful you need to figure out a way to make automating those fragile deployment steps easy (and solid). This is a problem lots of configuration management tools are trying to solve (chef, puppet, ansible, fabric, capistrano etc). Or at least help integrate deploy.do with such tools.

_query 12y ago
We provide hooks in our deployment process which you can use to do these kind of tasks. E.g. if you have to restart your web server after your deployment you will typically add something like `sudo service httpd restart` into the hook. If you have a really complex deployment process and need more than just our hooks we are not the right tool for solving your problem. But for your typically php or rails application you will be happy with deploydo :)

iancarroll 12y ago

This is difficult for some setups, as it relies on an open SSH port. Our AWS instances are not publicly accessible, so this makes it hard.

bowlofpetunias 12y ago

"Ever asked yourself why deploying your projects to your servers is such a pain?" I know exactly why it's such a pain. Because every deployment tool available only deals with the easy parts.