Reasons of failed introductions. Place of static analysis in the DevOps process. Static analysis – friend or foe. Notifications about analysis results. What to do with 10 000 analyzer warnings after the first run? How much time is needed for fixing all bugs? Q&A or what’s next?

1. What a DevOps
specialist has to
know about static
code analysis
Evgeniy Ryzhkov, PVS-Studio

2. About me
• Evgeniy Ryzhkov – CEO and
cofounder of PVS-Studio;
• The company was founded in 2008;
• The office is in Tula (125 miles from
Moscow), 30 employees;
• PVS-Studio is a static code analyzer
for C, C++, C# and Java on
Windows, Linux and macOS
• «CEO? When were you last coding,
CEO?»

3. Not another word about PVS-Studio…

4. Content
• Reasons of failed introductions.
• Place of static analysis in the DevOps process.
• Static analysis – friend or foe.
• Notifications about analysis results.
• What to do with 10 000 analyzer warnings after the first run?
• How much time is needed for fixing all bugs?
• Q&A or what’s next?

5. What is static code analysis?
… and what people tell about it on conferences.

6. Reasons of failed introductions
• Technical.
• Technical.
• Technical.
• Structural.

7. Place of static analysis in the
DevOps process
• Yegor Bugaenko. “It is quantity, not quality, that matters!”
• Automated Build
• Unit Tests
• Test Coverage
• Mutation Coverage
• Static Analysis
• Code Reviews
• Read-Only Master
Video of this talk at DevOpsConf Moscow 2018:
https://devopsconf.io/moscow/2018/abstracts/3723

8. Static analysis – friend or foe (when,
how and why)
• How to avoid shame?
• Depending on how and where the tool is introduced, people have different
attitude towards it. And a programming language has nothing to do with it.
• An error is found and immediately fixed? Great, atta boy!
• An error found on the build server? Anyone can see me failing, let’s shut
off this analyzer!

9. Analysis results mailing (to all or not
to all)
• Obvious pros and unobvious cons.
• A programmer has more important things to do tomorrow than fixing
today’s bug. Indeed, important things are more significant at some point,
but the bug then fades from memory.

10. Who else should get mails
• In some cases you need to copy your manager in (not the best option);
• It’s a good idea to copy your colleagues in for learning;
• It’s ok to copy your team lead in on the progress of fixing bugs.

11. What to do with 10 000 analyzer
warnings after the first run?
•NO-THING!

12. How much time is needed for fixing all
bugs?
• Expectations • Reality
0
5
10
15
20
25
1 2 3 4 5
Warnings
0
5
10
15
20
25
1 2 3 4 5
Warnings

13. So how much time is needed?
• Project size: 10 million lines of code
• Number of analyzer warnings: 5 thousand
• Team: 3-4 persons
• Time for fixing: 3-4 months
• Overall effort: 10-15 person-months
• Why you cannot use this data for proper estimation :-)

14. Conclusion
• Static analysis is not just a technical process, but first of all structural.
• Effectiveness of static analysis introduction and usage depends on right
process management.
• A manager (team lead, PM, CTO) has to be responsible for the right
process, but a DevOps specialist has to understand the core of the
process and suggest a manager if he doesn’t know some things.
• Such practice when an enthusiast promotes this technology in a company
gave a good showing

15. Q&A or what’s next
• Download the analyzer, check it out.
• Teach your colleagues, introduce it in your project.
• Get a promotion and a bonus for introduction of new modern practices :-)
The main idea that you should remember from this talk:
• In the next few years static analysis will measure up to unit tests or version
control systems. We used to live without them, but «this is no way to live».