10 ms·

If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break bec

If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break because of some completely unrelated team's code.

roguecoder 1y ago
If it is possible for that other team to merge a broken build, you are doing it wrong. If you are concerned about someone else breaking your thing, good! You were going to eventually break it yourself. Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.
- tuckerman 1y ago
  Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.
  - roguecoder 1y ago
    That's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying. The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.
    - mjr00 1y ago
      > I have yet to see a microservice architecture that automatically runs end to end tests before deploying. One of the big tenets of independent services is that your APIs are contracts that don't change behaviour. As long as each individual service doesn't introduce breaking changes, the system as a whole should work as expected. If it doesn't this is indicative of either 1) a specific service lacking test coverage, or 2) doing something wrong i.e. directly reading from a microservices' database without going through an API.
      - triceratops 1y ago
        > One of the big tenets of independent services is that your APIs are contracts that don't change behaviour How is that any different from an API in a monolith not changing behavior?
    - tuckerman 1y ago
      Yes, I suspect some of the back and forth is the fuzziness of the term "broken build", whether that means the code literally doesn't compile or it does but the code does the wrong thing. I agree that you can prevent merges that cause compilation errors in nearly all cases!
- jimbokun 1y ago
  What about when it’s you breaking your own thing? A very large code base full of loosely related functionality makes it more and more likely a change in one part will break another part in unexpected ways.
- motorest 1y ago
  > If it is possible for that other team to merge a broken build, you are doing it wrong. This assertion is unrealistic and fails to address the problem. The fact that builds can and do break is a very mundane fact of life. There are whole job classes dedicated to mitigate the problems caused by broken builds, and here you are accusing others of doing things wrong. You cannot hide this away by trying to shame software developers for doing things that software developers do. > Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code. That observation is so naive that casts doubt on whether you have any professional experience developing software. There are a myriad of ways any commit can break something that goes well beyond whether it compiles or not. Why do you think that companies, including FANGs, still hire small armies of QAs to manually verify if things still work once deployed? Is everyone around you doing things wrong, and you're the only beacon of hope? Unreal.
  - roguecoder 1y ago
    I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free software. I've gone seven months without a bug in production and the one we saw we had a signed letter from product saying "I am okay if this feature breaks, because I think writing the tests that can verify this integration was going to take too long." FAANG companies aren't prioritizing writing software well: they are prioritizing managing 50,000 engineers. Which is a much harder problem, but the management solutions that work for that preclude the techniques that let us write bug-free software. One of the great things about startups is that it is trivial to manage five engineers, so there is no reason we have to write software badly.
    - JackSlateur 1y ago
      You are absolutely right. Of course, if people wrote bug-free code, then there would be no bug ! Bug-free code in the actual code, or bug-free code in the test code, this is the same story. If you write stuff and never have any bug, then either: - you are lying - you do not write much - you only write really simple things - you are Jesus, came back from heaven to shine his light on us, poor souls The more complicated, intricate stuff you have, the more bugs you'll get (and only time will allow you to fix that). Tests are great do define how you think it should work, and to ensure it keeps doing that way. Take the time to think about the third point on the bullet list above.
jounker 1y ago
You’ll still get some isolation since not all pathways share the same code. It’s not all or nothing.
DanielHB 1y ago
You have a point, but I wouldn't say this is a big deal unless there is a mammoth dependency somewhere that slow down things to a crawl. Then maybe that one part of the codebase can be broken into its own separate service. But even then there are ways around this kind of problem with dynamic linking pre-built binaries and caching, but it is extra complexity that could be worse than managing multiple services. Docker cache can usually handle this pretty well though.

roguecoder 1y ago

If it is possible for that other team to merge a broken build, you are doing it wrong. If you are concerned about someone else breaking your thing, good! You were going to eventually break it yourself. Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.

tuckerman 1y ago
Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.
- roguecoder 1y ago
  That's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying. The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.
  - mjr00 1y ago
    > I have yet to see a microservice architecture that automatically runs end to end tests before deploying. One of the big tenets of independent services is that your APIs are contracts that don't change behaviour. As long as each individual service doesn't introduce breaking changes, the system as a whole should work as expected. If it doesn't this is indicative of either 1) a specific service lacking test coverage, or 2) doing something wrong i.e. directly reading from a microservices' database without going through an API.
    - triceratops 1y ago
      > One of the big tenets of independent services is that your APIs are contracts that don't change behaviour How is that any different from an API in a monolith not changing behavior?
  - tuckerman 1y ago
    Yes, I suspect some of the back and forth is the fuzziness of the term "broken build", whether that means the code literally doesn't compile or it does but the code does the wrong thing. I agree that you can prevent merges that cause compilation errors in nearly all cases!
jimbokun 1y ago
What about when it’s you breaking your own thing? A very large code base full of loosely related functionality makes it more and more likely a change in one part will break another part in unexpected ways.
motorest 1y ago
> If it is possible for that other team to merge a broken build, you are doing it wrong. This assertion is unrealistic and fails to address the problem. The fact that builds can and do break is a very mundane fact of life. There are whole job classes dedicated to mitigate the problems caused by broken builds, and here you are accusing others of doing things wrong. You cannot hide this away by trying to shame software developers for doing things that software developers do. > Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code. That observation is so naive that casts doubt on whether you have any professional experience developing software. There are a myriad of ways any commit can break something that goes well beyond whether it compiles or not. Why do you think that companies, including FANGs, still hire small armies of QAs to manually verify if things still work once deployed? Is everyone around you doing things wrong, and you're the only beacon of hope? Unreal.
- roguecoder 1y ago
  I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free software. I've gone seven months without a bug in production and the one we saw we had a signed letter from product saying "I am okay if this feature breaks, because I think writing the tests that can verify this integration was going to take too long." FAANG companies aren't prioritizing writing software well: they are prioritizing managing 50,000 engineers. Which is a much harder problem, but the management solutions that work for that preclude the techniques that let us write bug-free software. One of the great things about startups is that it is trivial to manage five engineers, so there is no reason we have to write software badly.
  - JackSlateur 1y ago
    You are absolutely right. Of course, if people wrote bug-free code, then there would be no bug ! Bug-free code in the actual code, or bug-free code in the test code, this is the same story. If you write stuff and never have any bug, then either: - you are lying - you do not write much - you only write really simple things - you are Jesus, came back from heaven to shine his light on us, poor souls The more complicated, intricate stuff you have, the more bugs you'll get (and only time will allow you to fix that). Tests are great do define how you think it should work, and to ensure it keeps doing that way. Take the time to think about the third point on the bullet list above.

jounker 1y ago

You’ll still get some isolation since not all pathways share the same code. It’s not all or nothing.

DanielHB 1y ago

You have a point, but I wouldn't say this is a big deal unless there is a mammoth dependency somewhere that slow down things to a crawl. Then maybe that one part of the codebase can be broken into its own separate service. But even then there are ways around this kind of problem with dynamic linking pre-built binaries and caching, but it is extra complexity that could be worse than managing multiple services. Docker cache can usually handle this pretty well though.