this post was submitted on 02 Feb 2024
198 points (91.2% 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

Related discussion-focused communities

founded 2 years ago
MODERATORS
 

So, what are you guys up to?

you are viewing a single comment's thread
view the rest of the comments
[–] stevecrox@kbin.run 2 points 10 months ago* (last edited 10 months ago)

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).