this post was submitted on 02 Feb 2024
202 points (91.4% liked)
[Outdated, please look at pinned post] Casual Conversation
6586 readers
1 users here now
Share a story, ask a question, or start a conversation about (almost) anything you desire. Maybe you'll make some friends in the process.
RULES
- Be respectful: no harassment, hate speech, bigotry, and/or trolling
- Encourage conversation in your post
- Avoid controversial topics such as politics or societal debates
- Keep it clean and SFW: No illegal content or anything gross and inappropriate
- No solicitation such as ads, promotional content, spam, surveys etc.
- Respect privacy: Don’t ask for or share any personal information
Related discussion-focused communities
- !actual_discussion@lemmy.ca
- !askmenover30@lemm.ee
- !dads@feddit.uk
- !letstalkaboutgames@feddit.uk
- !movies@lemm.ee
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
DevSecOps is all about process, I simplified my answer.
At a high level in software there will always be a review phase, where code needs to be built and pass tests (as a minimum). With Git being used by every organisation I have been involved in you will find the organisation/team will claim to follow a variation of 'Feature branch Workflow' with review happening at a specific point (Pull Request).
For the last ~10 years every organisation/team I've worked in/with has claimed to use a CI to verify the source code as part of that review phase.
In most dysfunctional teams that review phase will be broken, the fastest win is to bring in the CI. Static analysis tools are also impartial in how they review and useful in teaching people how to review.
I don't say your project must build with no warnings, I say you project must build and I'll have the CI point out where you have added warnings as part of review. When people complain I'll point to their teams Ways of Working or an organisations Software Development Plan (or in one case a System Engineering Management Plan).
The sort of team that then chooses to disable this will do so because the leadership are undermining it (normally a team lead turns it off or tells them to just ignore it). There seem to be a few common reasons as to why team leads will do this but it isn't something you can rationally debate with. The only solution I've found is to sideline the problem, change team culture and identify a leader within the team and hand it over to them.
Your talking about teams which are failing due to the environment, those normally understand what is wrong and the best approach is to be a good scrum master (e.g. run retro sessions, identify issues and work to resolve the environment problems with them).