5 ms·

OK I get what you're saying, but honestly, who is really 'losing productivity'? I suspect the ones saying they are in fact just getting on with other tasks they

by kjjw 11y ago

OK I get what you're saying, but honestly, who is really 'losing productivity'? I suspect the ones saying they are in fact just getting on with other tasks they can do because they are, despite github, still using distributed version control and do have access to and the ability to commit to code repositories. You don't need to host your own git daemon or github clone to get that functionality. I don't use github because it gives me a git daemon. I use it because the interface allows me interact with non-technical people when dealing with code and resources. I use github because, even though it is down right now, my stuff is backed up, I don't have to deal with the nitty gritty of ensuring backups succeed, I don't have to deal with the system when it goes down - someone else does that for me. Hence I would never want to run a local github clone.

kmfrk 11y ago
It kinda sucks when you rely on continuous integration, though.
- ad-hominem 11y ago
  Can't you just run your tests locally?
vacri 11y ago
I guess no-one else has deployment scripts that pull from github, just because you don't have them.
- zymhan 11y ago
  GitHub isn't made for that though, if you need scripts to pull downm files for important work, then you should really be storing that stuff in S3. And probably some other place you can switch to if something goes wrong.
  - _asummers 11y ago
    Someone pushed code to master or some other specified pre-master branch. Jenkins pulls down, builds, runs tests, uploads artifacts to S3. That doesn't sound unrealistic or risky on the surface, modulo relying on both GH and S3 being up. Arguably you should be able to mirror on both an internal git repository somewhere, but GitHub is down infrequently enough that it's hard to justify that work + continuing costs if you don't have your own hardware + security patching + other admin costs to managers until you see multiple outages in a small enough window.
    - bryanlarsen 11y ago
      That sounds exactly like our deployment strategy, and I can push to production when GitHub is down. What's preventing you from copying & pasting the build script from Jenkins into a terminal in a local checkout? S3 being down would be a show stopper, but GH being down is just really annoying.
      - _asummers 11y ago
        What about the code it has to build? Where does that come from? What about third party libraries it has to pull in? If the only thing the build server needed to build your code was the build script, this would be easy.
        bryanlarsen 11y ago
        The code is building is coming from the local checkout. As for third party libraries, npm used to be so unreliable that we needed a strategy for that.
        _asummers 11y ago
        Checkout from where? I'm not being dense, but new code has to come from SOMEWHERE. If GH (or wherever your code is hosted) is down, the checkout won't be able to happen. Development isn't generally done on the build box.
  - vacri 11y ago
    Yes, for production assets. But that's not the only thing deployment scripts serve. Tomorrow we're trying out a feature branch on our staging servers, and will be pulling from Bitbucket as we iterate. If Bitbucket goes down, we can work around it, but we still 'lose productivity' because we're spending our time working around it. Yes, the devs can 'work on other things', but tomorrow's feature branch is what's on their mind, and it's what the sprint target is. It doesn't matter what kind of deployment you do. Even s3 has outages if the network between you and s3 bites the dust. Even if you deploy straight from the developer's workstation to the production server, you can have an outage - network splits, hardware failure, developer-with-commit-rights gets sick. Working around an outage means you're not working on the product, and that's a loss of productivity.
johnchristopher 11y ago
I diaagree on some points: github/git is not an appropriate backup strategy and github is not user friendly enough for non technical people (the default repository page, github pages is another matter).
- acdha 11y ago
  Do you have any support for those assertions? In particular, the backup claim is rather dubious unless you're redefining “backup” to be a much higher bar than most common answers meet.
  - johnchristopher 11y ago
    Git is a distributed revision control system and designed as such. The fact it can be used as a back-up tool doesn't mean it should be used as a back-up tool, especially when there are back-up solutions designed from the ground to do just that.
    - acdha 11y ago
      But what you actually said was “Github/git is not an appropriate backup strategy”. Git is tamper-evident and uses strong hashes to protect against bitrot, has full change tracking and numerous measures to avoid data-loss becoming permanent if you detect human error before weeks/months go by, has integrated remote tracking so you can tell how stale your off-site copies are and trivially update them, and most server implementations allow as much access control as you desire. Assuming that we're talking about things which are already stored in Git and not e.g. an HD video collection, what would make your original statement true?

by kjjw 11y ago

kmfrk 11y ago

It kinda sucks when you rely on continuous integration, though.

ad-hominem 11y ago
Can't you just run your tests locally?

vacri 11y ago

I guess no-one else has deployment scripts that pull from github, just because you don't have them.

zymhan 11y ago
GitHub isn't made for that though, if you need scripts to pull downm files for important work, then you should really be storing that stuff in S3. And probably some other place you can switch to if something goes wrong.
- _asummers 11y ago
  Someone pushed code to master or some other specified pre-master branch. Jenkins pulls down, builds, runs tests, uploads artifacts to S3. That doesn't sound unrealistic or risky on the surface, modulo relying on both GH and S3 being up. Arguably you should be able to mirror on both an internal git repository somewhere, but GitHub is down infrequently enough that it's hard to justify that work + continuing costs if you don't have your own hardware + security patching + other admin costs to managers until you see multiple outages in a small enough window.
  - bryanlarsen 11y ago
    That sounds exactly like our deployment strategy, and I can push to production when GitHub is down. What's preventing you from copying & pasting the build script from Jenkins into a terminal in a local checkout? S3 being down would be a show stopper, but GH being down is just really annoying.
    - _asummers 11y ago
      What about the code it has to build? Where does that come from? What about third party libraries it has to pull in? If the only thing the build server needed to build your code was the build script, this would be easy.
      - bryanlarsen 11y ago
        The code is building is coming from the local checkout. As for third party libraries, npm used to be so unreliable that we needed a strategy for that.
        _asummers 11y ago
        Checkout from where? I'm not being dense, but new code has to come from SOMEWHERE. If GH (or wherever your code is hosted) is down, the checkout won't be able to happen. Development isn't generally done on the build box.
- vacri 11y ago
  Yes, for production assets. But that's not the only thing deployment scripts serve. Tomorrow we're trying out a feature branch on our staging servers, and will be pulling from Bitbucket as we iterate. If Bitbucket goes down, we can work around it, but we still 'lose productivity' because we're spending our time working around it. Yes, the devs can 'work on other things', but tomorrow's feature branch is what's on their mind, and it's what the sprint target is. It doesn't matter what kind of deployment you do. Even s3 has outages if the network between you and s3 bites the dust. Even if you deploy straight from the developer's workstation to the production server, you can have an outage - network splits, hardware failure, developer-with-commit-rights gets sick. Working around an outage means you're not working on the product, and that's a loss of productivity.

johnchristopher 11y ago

I diaagree on some points: github/git is not an appropriate backup strategy and github is not user friendly enough for non technical people (the default repository page, github pages is another matter).

acdha 11y ago
Do you have any support for those assertions? In particular, the backup claim is rather dubious unless you're redefining “backup” to be a much higher bar than most common answers meet.
- johnchristopher 11y ago
  Git is a distributed revision control system and designed as such. The fact it can be used as a back-up tool doesn't mean it should be used as a back-up tool, especially when there are back-up solutions designed from the ground to do just that.
  - acdha 11y ago
    But what you actually said was “Github/git is not an appropriate backup strategy”. Git is tamper-evident and uses strong hashes to protect against bitrot, has full change tracking and numerous measures to avoid data-loss becoming permanent if you detect human error before weeks/months go by, has integrated remote tracking so you can tell how stale your off-site copies are and trivially update them, and most server implementations allow as much access control as you desire. Assuming that we're talking about things which are already stored in Git and not e.g. an HD video collection, what would make your original statement true?