Bugs and Where to Find Them (Study Case_ Backend).pdf

1. Bugs and Where to Find Them (Study Case:
Backend)
Ridwan @SenseHealth B.V.
28th August 2019

2. Principles
● ISO 27001,
● ITIL v4, Service Management Practice No.5 (Incident Management) and No. 7
(Monitoring and Event Management)
● NEN 7510-2:2017, Section No. 12 Business Management Security: Capacity
Management, Separation of Development Environment, Reporting and Monitoring,
etc.

3. Incident
● High CPU Usage
● High RAM Usage
● Run out of disk space
● Network problem from
third-party
● Misconfiguration
● etc

4. Bugs
● Mismatch logic against
requirements
● Incompatible packages
● Bugs from third-party
libraries
● Unseen bugs
● etc

5. Conventional Bug
Tracing

6. Case - 1
1. QA help identifying the bugs
2. Single Baremetal Server
3. One person as System Administrator
4. Checking the apache log by himself alone
5. Other developers couldnʼt check the log directly
6. Finally check the bugs directly on the webpages by using “echo” and “print_r”

7. Case - 2
1. No QA
2. Users / Clients report the bugs directly to the developers
3. Multiple of VPS Instances
4. More than one System Administrator
5. Others developer may access the log for debugging purposes with an agreement
and rules
6. Developer access the log directly to the servers

8. Modern Bug
Tracing

9. Case - 1
1. QA identifying the bugs
2. Bugs exceed logs from AWS ElasticBeanstalk
3. Developers could trace the bugs through AWS Cloudwatch
4. System Administrator set the rules for which developer who are able to open AWS
Cloudwatch
5. Report back to QA
6. Create an issue at Github

10. Case - 2
1. QA Identify the bugs
2. System Administrator trace the logs through centralized log management
3. Bugs catched by apps send the error / exception to the bug management system
(Sentry)
4. Sentry Integration with Github
5. Even if the QA didnʼt report bugs, the bugs are still being catched automatically
6. Send a report automatically to communication channel
7. Confirmed bugs will be created as a Github Issue

11. SenseHealth
Architecture
Log and Bug Tracing Management

12. SenseHealth Architecture

13. Case 1
1. QA report a potential bugs along with the timerange of the event
2. QA provide information regarding the affected environment
3. Ops will trace the bugs through ELK stack
4. Found some suspected errors from http request within timerange
5. Check the event with Sentry event
6. Found bugs and report the bugs to the platform lead
7. Report back to QA
8. Platform lead will create Github issue for that

14. Case 2
1. QA report a potential bugs along with the timerange of the event
2. QA provide information regarding the affected environment
3. Ops will trace the bugs through ELK stack
4. Didnʼt find some suspected errors from http request within timerange
5. Check the event with Sentry event
6. Didnʼt find bugs and report the bugs to the platform lead
7. Pair programming and manual tracing
8. Report back to QA
9. Platform lead will create Github issue for that

15. Case 3
1. Similar story to case 2
2. But after pair programming the expected result and flow are still match with the
requirements
3. Possibly bugs are produced at the client side
4. Report back to QA

16. Conclusions
1. Build an accessible application logs for widerange developers
a. Report the bugs before the other stakeholder noticed it
b. Donʼt let unauthorized person touch the servers
2. Follow some principles from IT management standards
a. Periodically meeting is required
b. Pair programming is needed to evaluate pull request review
c. Cooperate with QA to gain bugs information
3. Being proactive even there are no any potential bugs

17. Question?