3 ms·

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 t

by _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)
encoderer 12y ago
I'd really like you to make a case for why I, as somebody who won't store production credentials in my code repo, should feel good storing them in yours. I run the a SaaS cron monitoring service (Cronitor.io) and we ourselves make liberal use of SaaS tools to simplify our lives and free us to focus our time on places we can add value. But I'm skeptical of storing all the things our apps need -- private keys, passwords, paths, ports and hostnames -- with you. And that doesn't even touch on the risk that if somebody compromised you, wouldn't they essentially have a key to the back door of every one of your customers? What have you done to mitigate that risk? Aside from all that, congrats on shipping! It's an important milestone.
- _query 12y ago
  Currently we are working on improving our security by encrypting user data like config files. Then we would store the password for decrypting these data on the client. We would only decrypt these things when required (e.g. when deploying). Note that this is currently only a concept and not implemented yet. Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised. > Aside from all that, congrats on shipping! It's an important milestone. Thanks :)
  - encoderer 12y ago
    > Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised. Right, which is why you don't put your credentials in your source code on Github. This is common practice and one you seem to accommodate in your product, so I know you're very familiar with it... I hope you guys are transparent about these sort of things, it will mean a lot to your adoption rate I think. A lot of people out there who could be interested in a tool like this if they felt comfortable with the security implications.

by _query 12y ago

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)

encoderer 12y ago

I'd really like you to make a case for why I, as somebody who won't store production credentials in my code repo, should feel good storing them in yours. I run the a SaaS cron monitoring service (Cronitor.io) and we ourselves make liberal use of SaaS tools to simplify our lives and free us to focus our time on places we can add value. But I'm skeptical of storing all the things our apps need -- private keys, passwords, paths, ports and hostnames -- with you. And that doesn't even touch on the risk that if somebody compromised you, wouldn't they essentially have a key to the back door of every one of your customers? What have you done to mitigate that risk? Aside from all that, congrats on shipping! It's an important milestone.

_query 12y ago
Currently we are working on improving our security by encrypting user data like config files. Then we would store the password for decrypting these data on the client. We would only decrypt these things when required (e.g. when deploying). Note that this is currently only a concept and not implemented yet. Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised. > Aside from all that, congrats on shipping! It's an important milestone. Thanks :)
- encoderer 12y ago
  > Otherwise the same applies to GitHub: If GitHub gets hacked, your application details will also be compromised. Right, which is why you don't put your credentials in your source code on Github. This is common practice and one you seem to accommodate in your product, so I know you're very familiar with it... I hope you guys are transparent about these sort of things, it will mean a lot to your adoption rate I think. A lot of people out there who could be interested in a tool like this if they felt comfortable with the security implications.