4 ms·

We just had a discussion about this a couple of hours ago. If your deployment depends on an external service, your deployment is broken. You're using git. Have

We just had a discussion about this a couple of hours ago. If your deployment depends on an external service, your deployment is broken. You're using git. Have a fabric script that pulls down the remote repositories that you need, and rsync's them to your servers. This works locally or on a remote box. If github is down, pass in local directory to sync instead. This way you can always push. He built his infrastructure wrong, and is trying to blame someone else. Sorry, but you are just as much at fault, if not more, than github.

zacharypinter 17y ago
I don't think that's an entirely fair argument to make. For example, I don't think it's unreasonable to write a unit test that expects an SMTP server to be available. Maybe doing so would break the deploy if the SMTP server ever went down, but at that point you have two options: rearchitect your deploy, or find a more reliable SMTP server to test against. If the author would rather spend his time and money looking for a more reliable git host than rearchitecting his deploy to account for service failures, why is that so bad?
- vulf 17y ago
  I've actually been in that exact situation. Yes, the unit test should expect that once it offloads the message to the SMTP server that everything works correctly, but there should also be another set of tests that ensures the app fails gracefully when the SMTP server is not there. Once you have that, then you should find a more reliable solution to the STMP server failures.
- vidarh 17y ago
  It is so bad because it fails to take into account that there are multiple failure points involved (his git host, his internet connectivity, multiple transit providers and routers beyond either his or his hosts control, electricity supply etc.) and that getting a more reliable git host won't even address one of them - no hosting will ever achieve 100% uptime, if only because of eventual human error. He'd be better served first addressing the significant flaw in his overall process of not having a fallback that bypasses as many failure points as possible. I.e. why does he not have a constantly updated clone of the repositories locally at the provider hosting his actual sites, so that he can deploy as long as he can get hold of an internet connection somehow and is able to connect to his hosting environment? This bypasses the local electricity supply, his office internet connection, the transit providers between him and Github, etc., because there are many easily accessible ways of getting an ssh connectio in a pinch, and the remaining dependency is his production hosting, without which deployment wouldn't work anyway. It would be a simple, cheap and prudent safety mechanism if being able to deploy immediately is business critical for him. It's a matter of a single command in a crontab on one or more of his production servers.

zacharypinter 17y ago

I don't think that's an entirely fair argument to make. For example, I don't think it's unreasonable to write a unit test that expects an SMTP server to be available. Maybe doing so would break the deploy if the SMTP server ever went down, but at that point you have two options: rearchitect your deploy, or find a more reliable SMTP server to test against. If the author would rather spend his time and money looking for a more reliable git host than rearchitecting his deploy to account for service failures, why is that so bad?

vulf 17y ago
I've actually been in that exact situation. Yes, the unit test should expect that once it offloads the message to the SMTP server that everything works correctly, but there should also be another set of tests that ensures the app fails gracefully when the SMTP server is not there. Once you have that, then you should find a more reliable solution to the STMP server failures.
vidarh 17y ago
It is so bad because it fails to take into account that there are multiple failure points involved (his git host, his internet connectivity, multiple transit providers and routers beyond either his or his hosts control, electricity supply etc.) and that getting a more reliable git host won't even address one of them - no hosting will ever achieve 100% uptime, if only because of eventual human error. He'd be better served first addressing the significant flaw in his overall process of not having a fallback that bypasses as many failure points as possible. I.e. why does he not have a constantly updated clone of the repositories locally at the provider hosting his actual sites, so that he can deploy as long as he can get hold of an internet connection somehow and is able to connect to his hosting environment? This bypasses the local electricity supply, his office internet connection, the transit providers between him and Github, etc., because there are many easily accessible ways of getting an ssh connectio in a pinch, and the remaining dependency is his production hosting, without which deployment wouldn't work anyway. It would be a simple, cheap and prudent safety mechanism if being able to deploy immediately is business critical for him. It's a matter of a single command in a crontab on one or more of his production servers.