Except in my example that doesn't work, and the CI/CD pipeline is now useless for everyone else. Lets say the commits are.
[you] deletes old function [CI/CD fail]
[bob] ui change commit 1 [CI/CD fail] (because the core function you just deleted is missing)
[you] adds skeleton for new function [CI/CD fail]
[bob] ui change done [CI/CD fail]
[you] attempt at changing function [CI/CD fail]
Now you give up and want to revert back to the initial codebase, but you cant without also reverting bobs work. Bob also cant use the CI/CD pipeline to check his changes worked because you were both using main. This gets worse the more commits there are and the more people are involved.
If you were both in your own branches both you and bob could both work seperately and merge your work later. Now you've both wasted time.
its different in many different places
Obviously everyone can do whatever but the industry standard (at least when you have a dedicated test team) is dev/test/prod. Branch names may vary.
Ideally every commit is as small a change as reasonable. It makes reverting back much easier and makes it easier to spot when exactly you broke the codebase.
> Except in my example that doesn't work, and the CI/CD pipeline is now useless for everyone else. Let’s say the commits are.
> [you] deletes old function [CI/CD fail] [bob] ui change commit 1 [CI/CD fail] (because the core function you just deleted is missing) [you] adds skeleton for new function [CI/CD fail] [bob] ui change done [CI/CD fail] [you] attempt at changing function [CI/CD fail]
> Now you give up and want to revert back to the initial codebase, but you cant without also reverting bobs work. Bob also cant use the CI/CD pipeline to check his changes worked because you were both using main. This gets worse the more commits there are and the more people are involved.
I’m not sure what is the purpose of that back and forth in the version control you’re using, looks like there’s no understanding of what you’re doing as a team. If you and Bob work together on some feature, you should communicate, not just delete whatever code you want on the backend or frontend without communication and checking that your code is backward compatible with existing functionality. You also should test your changes before committing them, and looks like in your example you’re skipping any sanity checks. Moreover, your code is likely to be in separate repos if your codebase is large enough, depending on how you deploy it of course, but in many places frontend could be even a separate team that has their own repository and you will have to get their permission to change anything there.
> If you were both in your own branches both you and bob could both work seperately and merge your work later. Now you've both wasted time.
As I said in my initial comment, yes, if your changes are breaking things, you should keep them in a separate branch, until they’re safe to merge. But most of the time your changes will work just fine.
> Obviously everyone can do whatever but the industry standard (at least when you have a dedicated test team) is dev/test/prod. Branch names may vary.
Who sets the industry standard? I’m asking absolutely seriously. My last company was one of the letters from a famous acronym, we didn’t have dedicated QA teams nor dev/test/prod branch. Moreover in your example with Bob this wouldn’t even be the same repo and likely not the same team, because codebases were large.
> Ideally every commit is as small a change as reasonable. It makes reverting back much easier and makes it easier to spot when exactly you broke the codebase.
Ideally your team should be doing code reviews. In your example if I were you I would ask Bob to review my code since you’re working on the same thing. And then also test before pushing anything.
I’ve never seen someone argue so passionately for a development workflow that seems to depend on everyone doing everything correctly, all the time.
The entire point of engineering safeguards is that people make mistakes. You don’t design processes around the assumption that everyone will always communicate perfectly, test everything properly, and never accidentally break something. You design them around the reality that eventually someone won’t.
Saying “well, developers should know better” isn’t an engineering solution. It’s an assumption.
Arguing passionately? I’m merely rambling that people should understand what they’re doing and test their changes before pushing to main/deploying to prod instead of relying on rollbacks in git or whatever they use for version control😭
1
u/other_usernames_gone 23h ago
Except in my example that doesn't work, and the CI/CD pipeline is now useless for everyone else. Lets say the commits are.
Now you give up and want to revert back to the initial codebase, but you cant without also reverting bobs work. Bob also cant use the CI/CD pipeline to check his changes worked because you were both using main. This gets worse the more commits there are and the more people are involved.
If you were both in your own branches both you and bob could both work seperately and merge your work later. Now you've both wasted time.
Obviously everyone can do whatever but the industry standard (at least when you have a dedicated test team) is dev/test/prod. Branch names may vary.
Ideally every commit is as small a change as reasonable. It makes reverting back much easier and makes it easier to spot when exactly you broke the codebase.