Interesting article, thanks! But in what kind of workflow can one dev break the build for everyone? Are you pushing directly to master/trunk/whatever the main branch is called in your SCM? There is no way it can happen if you use a workflow where the code is pushed to a branch until it's built and reviewed, and only code that builds successfully can be merged.
Focused on creating wonderful user experiences by attending to folks needs with empathy and creating spaces of safety. Senior Frontend Developer/Tech Lead at Dolittle.
Great observation and input, Thomas. Yes! Code reviews / PR's will definitely eliminate most trivial issues. Pre-merge builds/tests would probably get rid of the others. Great advice for anyone not already doing them.
Not all teams are at this level of automation / process though. And builds can still fail. There's always the potential for the packaging / deployment steps to fail though.
Which leads me back to this article: how does the team react when it does?
Be well,
Pavneet
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting article, thanks! But in what kind of workflow can one dev break the build for everyone? Are you pushing directly to master/trunk/whatever the main branch is called in your SCM? There is no way it can happen if you use a workflow where the code is pushed to a branch until it's built and reviewed, and only code that builds successfully can be merged.
Great observation and input, Thomas.
Yes! Code reviews / PR's will definitely eliminate most trivial issues. Pre-merge builds/tests would probably get rid of the others. Great advice for anyone not already doing them.
Not all teams are at this level of automation / process though. And builds can still fail. There's always the potential for the packaging / deployment steps to fail though.
Which leads me back to this article: how does the team react when it does?
Be well,
Pavneet