3 ms·

takes too long if your project is of reasonable size, why not just send the diff

• potatolicious 17y ago
  We're talking about deployment to production machines - what's the difference between 3 seconds and 5 minutes? Your machine is sitting on a fat pipe in a datacenter, where you can push a 300MB deploy (which is a LOT) trivially. I highly doubt you're rolling out code changes every 10 minutes... not to production anyway. Sending diffs removes your ability to roll back at all, or if you're somewhat devious about it, it still wouldn't allow you to roll back more than a single version. I'm surprised you're so concerned about time-to-deploy for an action that happens, what, once a day at most? Twice? The amount of safeguard you gain for the trivial non-human-time (it's not as if some guy is sitting there copying files) increase is pretty massive.
  • cominatchu 17y ago
    As other people mentioned, if you send the diff by, say, pulling from your git repository, then you can roll back to any tag or revision. What happens when your 300MB deploy needs to be pushed from your development machine out to 15 different production servers? I wouldn't want to send ~4.3GB for every deployment. Furthermore, a quick deployment time is valuable when a crucial fix needs to be pushed to production. This is not to mention the space that your 300MB deploy is going to take up on the hard drives of your production machines if you deploy twice a day. That's over 213GB a year per machine, sounds like you would need to start deleting old revisions. Or start just sending the diffs.