4 ms·

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

by zymhan 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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.
        bryanlarsen 12y ago
        I've got about 3 different checkouts of my code on my laptop right now, and each of my coworkers has at least one...
        _asummers 12y ago
        Again, how does that get to the build box? I also have several local copies of my code on my computer, but that doesn't help the Jenkins machine get it unless I scp (or whatever) it over.
        zymhan 12y ago
        You can copy whatever files you want with SCP or SFTP or any number of file transfer protocols.
  - vacri 12y ago
    Developers don't always have access rights to the build systems or artifact repositories. Most of the devs I work with don't - not because I'm not willing to share, but because they're supremely uninterested in the deployment systems. If there's an outage, the people who can fix it aren't always available right then and there.
vacri 12y 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.

by zymhan 12y ago

_asummers 12y 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 12y 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 12y 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 12y 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 12y 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.
      - bryanlarsen 12y ago
        I've got about 3 different checkouts of my code on my laptop right now, and each of my coworkers has at least one...
        _asummers 12y ago
        Again, how does that get to the build box? I also have several local copies of my code on my computer, but that doesn't help the Jenkins machine get it unless I scp (or whatever) it over.
        zymhan 12y ago
        You can copy whatever files you want with SCP or SFTP or any number of file transfer protocols.
- vacri 12y ago
  Developers don't always have access rights to the build systems or artifact repositories. Most of the devs I work with don't - not because I'm not willing to share, but because they're supremely uninterested in the deployment systems. If there's an outage, the people who can fix it aren't always available right then and there.

vacri 12y 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.