3 ms·

I thought google hasn't use perforce for years but something called piper[1]. Aren't migrations good on some aspects such as force engineers to stop using insec

I thought google hasn't use perforce for years but something called piper[1]. Aren't migrations good on some aspects such as force engineers to stop using insecure libraries? I would say you could do internal migrations without having to change external apis, maybe google should care about the customer more? or is there some other reason for these external forced migrations? [1]https://research.google/pubs/pub45424/ https://research.google/pubs/pub45424/

Normal_gaussian 5y ago
> Aren't migrations good on some aspects such as force engineers to stop using insecure libraries? Sure, but how many times have you deployed an update that you were sure was security? Most libs I work with are 90+% features or ease-of-use releases, the security is hand wavy to do with dependencies, or a very rare "oops".
- mattnewton 5y ago
  This is mitigated somewhat by having integration tests (which shine in migration-like situations like this despite their many other problems). You can write tests that defend you from some of the breakages at Google and guarantee they will be run.
  - pkhuong 5y ago
    And the ability to run automatically run tests on any part of the code base because everything uses Blaze. You can schedule your wide-reaching changes on the TAP train and see what breaks across the whole monorepo. In most cases, the library authors are responsible for driving the migration. This is different from third-party libraries adding causing pain to everyone else because they decided to change an interface without sending PRs to migrate all their users.
dekhn 5y ago
that's correct, the monorepo stopped being served by perforce many years ago (the efforts to keep it scaling were heroic). Instead, google made something which appears to be API-compatible with perforce (so the tooling continued to work) but is backed by Google technologies with the source hosted in the datacenters (which is kind of a circular situation).
- orf 5y ago
  Isn’t that circular dependency kind of risky? What if a bad deploy knocks offline something required to complete the rollback process for that bad deploy? I’m sure there are multiple layers of redundancy, but it seems like you could get into a Facebook style situation where you need to go open a (virtual) cage somewhere to flip a switch.
  - dekhn 5y ago
    Yes, it's risky but given all the alternatives, it makes the least nonsense. It works because there is massive redundancy and datacenters aren't all updated at the same time. When I worked at Google I worked in hardware platforms and I spent a lot of time working with hwops people, who have to go physically out to some server and press buttons (whilst chatting the results to me). If corp gmail, chat, and everything else was down, I might have some trouble getting in touch with those folks and verifying the right fixes (which is why the FB situation is so crazy).
    - ramraj07 5y ago
      Until something goes bad in a silly place like it did in Facebook and everything disappears everywhere for a good while. Because google is everything.
dietr1ch 5y ago
> I thought google hasn't use perforce for years but something called piper[1]. Yes, but for I guess the author wanted to keep things simple for outsiders. Piper is supposedly not much different than Perforce. Forgetting implementation details is just a centralized version control system that holds a monorepo and everyone* just test and build from trunk/master/head.

Normal_gaussian 5y ago

> Aren't migrations good on some aspects such as force engineers to stop using insecure libraries? Sure, but how many times have you deployed an update that you were sure was security? Most libs I work with are 90+% features or ease-of-use releases, the security is hand wavy to do with dependencies, or a very rare "oops".

mattnewton 5y ago
This is mitigated somewhat by having integration tests (which shine in migration-like situations like this despite their many other problems). You can write tests that defend you from some of the breakages at Google and guarantee they will be run.
- pkhuong 5y ago
  And the ability to run automatically run tests on any part of the code base because everything uses Blaze. You can schedule your wide-reaching changes on the TAP train and see what breaks across the whole monorepo. In most cases, the library authors are responsible for driving the migration. This is different from third-party libraries adding causing pain to everyone else because they decided to change an interface without sending PRs to migrate all their users.

dekhn 5y ago

that's correct, the monorepo stopped being served by perforce many years ago (the efforts to keep it scaling were heroic). Instead, google made something which appears to be API-compatible with perforce (so the tooling continued to work) but is backed by Google technologies with the source hosted in the datacenters (which is kind of a circular situation).

orf 5y ago
Isn’t that circular dependency kind of risky? What if a bad deploy knocks offline something required to complete the rollback process for that bad deploy? I’m sure there are multiple layers of redundancy, but it seems like you could get into a Facebook style situation where you need to go open a (virtual) cage somewhere to flip a switch.
- dekhn 5y ago
  Yes, it's risky but given all the alternatives, it makes the least nonsense. It works because there is massive redundancy and datacenters aren't all updated at the same time. When I worked at Google I worked in hardware platforms and I spent a lot of time working with hwops people, who have to go physically out to some server and press buttons (whilst chatting the results to me). If corp gmail, chat, and everything else was down, I might have some trouble getting in touch with those folks and verifying the right fixes (which is why the FB situation is so crazy).
  - ramraj07 5y ago
    Until something goes bad in a silly place like it did in Facebook and everything disappears everywhere for a good while. Because google is everything.

dietr1ch 5y ago

> I thought google hasn't use perforce for years but something called piper[1]. Yes, but for I guess the author wanted to keep things simple for outsiders. Piper is supposedly not much different than Perforce. Forgetting implementation details is just a centralized version control system that holds a monorepo and everyone* just test and build from trunk/master/head.