Thursday, May 21, 2026

Cohort 3 | Project CloudIgnite Topics: Debugging & Testing, DevOps & Continuous Integration Duration: ~3 hours

Key Takeaways

• Error types: syntax (easy), runtime (medium — read traceback), logical (hard — no crash, wrong output)
• Static vs dynamic analysis: code review without running vs debugging while running
• Debugging tools: pdb (command-line), VS Code debugger (breakpoints, watchers)
• Testing levels: Unit → Integration → System → Acceptance (UAT); use assert for validation
• Lab 130: Caesar cipher debugging — Type error (str vs int), logic error (lowercase not in alphabet), wrong parameter to decrypt
• DevOps: CALMS framework (Culture, Automation, Lean, Measurement, Sharing)
• CI/CD pipeline: Push → GitHub Action → Tests → Build → Deploy → Restart
• IaC: Infrastructure as Code (Terraform) — define infrastructure as code instead of manual console clicks

Table of Contents

1. Debugging & Testing
   • Types of Errors
   • Static vs Dynamic Analysis
   • Debugging Tools
   • Assertion & Log Monitoring
   • Types of Testing
2. Lab 130 — Debugging Caesar Cipher
   • Task 1 — Syntax / Type Error
   • Task 2 — Logic Error (lowercase handling)
   • Task 3 — Wrong Parameter Passed
3. DevOps & Continuous Integration
   • What is DevOps?
   • Software Development Methodologies
   • Automation Types & Risks
   • CI/CD
4. Lab 134 — DevOps Tools Research
5. AWS CLF-C02 Relevance
6. Key Takeaways & Tips

1. Debugging & Testing

1.1 Types of Errors

Tip: No software is 100% bug-free. 90–95% bug-free is considered acceptable in production.

1.2 Static vs Dynamic Analysis

1.3 Debugging Tools

Command-line Python debugger:

python3 -m pdb your_file.py

VS Code debugger (recommended):

• Set breakpoints (red dots) on lines where you want execution to pause
• Use Watchers to track variable values in real time
• Step through code line by line using the step controls

Useful debugger commands (pdb):

• n — next line
• p <variable> — print variable value
• c — continue to next breakpoint
• q — quit debugger

Debugging strategy tips from lecture:

• Put breakpoints on the last statement inside a loop to track each iteration
• If a loop has a conditional branch, put breakpoints on all branch endings
• Put a breakpoint on the last line of a function to inspect its local variables before they go out of scope
• When starting out, using print() statements is a perfectly normal approach

1.4 Assertion & Log Monitoring

Assertion — a condition that must be True for code to pass a test

• Used in unit testing to validate that a function produces the expected result
• If the condition is True → test passes; if False → test fails

Log Monitoring — tracking what a running program does over time

• Python's built-in logging library: import logging
• Most developers use print() for quick debugging; the logging library offers more features (log levels, timestamps, file output)
• Mobile crash reports (e.g. Google Play Store crash reports) use this same concept — they capture the stack trace from the user's device

1.5 Types of Testing

Unit Testing → Integration Testing → System Testing → Acceptance Testing (UAT)

Automated testing tools:

• Selenium — automates browser interactions; can click buttons, navigate pages, and generate a test report automatically (not a standard library — must be installed)

Code quality principles that make code testable:

• SOLID — five object-oriented design principles
• DRY — Don't Repeat Yourself
• KISS — Keep It Simple, Stupid
• Avoid "smelly code" — code that works but is hard to read, understand, or test; avoid putting everything into one massive function

2. Lab 130 — Debugging Caesar Cipher

2.1 Task 1 — Syntax / Type Error

Error observed:

TypeError: unsupported operand type(s) for +: 'int' and 'str'

Cause: The cipher key was passed in as a str (from input()), but was being added to an integer position.

Fix: Cast the cipher key to an integer:

cipher_key = int(input("Enter key: "))

Lesson: Read the stack trace from top to bottom — the last entry is the exact line causing the crash.

2.2 Task 2 — Logic Error (lowercase handling)

Symptom: Only uppercase letters were encrypted; lowercase letters passed through unchanged.

Root cause identified using the debugger:

• The alphabet list contained only uppercase letters (A–Z)
• When the current character was lowercase (e.g. 'e'), alphabet.index('e') returned -1 (not found)
• The if branch was skipped; the character was appended to the output unchanged

Fix (approach used in lab):

alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz"

Alternative fix: Convert the input to uppercase before encrypting (loses case information but works).

Lesson: When a loop processes characters conditionally, use the debugger to watch the value of the condition variable (position) on each iteration to spot where logic diverges.

2.3 Task 3 — Wrong Parameter Passed

Symptom: Encryption worked correctly, but decryption produced the wrong output.

Root cause: The decryptMessage() function was called with cipher_key instead of decrypt_key.

• For encryption, key = +n
• For decryption, key = -n (i.e. cipher_key * -1)
• The code computed decrypt_key = cipher_key * -1 but then accidentally passed cipher_key to the decrypt function

Fix:

# Wrong
decryptMessage(message, cipher_key)

# Correct
decrypt_key = cipher_key * -1
decryptMessage(message, decrypt_key)

Lesson: When encryption works but decryption doesn't, check that the inverse operation (negative key) is being passed correctly.

3. DevOps & Continuous Integration

3.1 What is DevOps?

DevOps is a software development culture and practice that unifies development and operations — covering code writing, testing, deployment, and infrastructure management.

Core pillars (CALMS):

• Culture — collaboration across all teams (Dev, QA, DB admin, IT infrastructure)
• Automation — automate repetitive tasks (builds, tests, deployments)
• Lean — eliminate waste in the process
• Measurement — track performance of the whole system
• Sharing — feedback loops between teams

Goal of DevOps:

• Bridge the gap between software development and quality assurance (QA)
• Reduce the need for manual, specialised work
• Enable faster, more reliable software delivery

3.2 Software Development Methodologies

Waterfall (Traditional)

• Sequential phases: Analyse → Plan → Design → Build → Test → Deploy
• Cannot go back to a previous phase once it is complete
• Rigid; suitable for well-defined, stable projects

Agile (Modern — used in most companies today)

• Software is split into sprints (short iterations, e.g. 2-week cycles)
• Each sprint: Analyse → Plan → [Design → Build → Test loop] → Deploy
• Clients and stakeholders can give feedback during development
• More flexible; new features or changes can be incorporated

DevOps fits naturally into Agile — automation handles the repetitive deploy/test cycle within each sprint.

3.3 Automation Types & Risks

Three areas of DevOps automation:

Three risks of automation:

3.4 CI/CD

Continuous Integration (CI)

• Every developer's code push is automatically tested against the existing codebase
• Ensures new code doesn't break what already works
• Code must be readable, maintainable, and testable so team members (including future hires) can continue working on it
• Uses tools like GitHub Actions to trigger tests on push

Continuous Delivery/Deployment (CD)

• After CI passes, code is automatically built and deployed
• Deployment environments:

Staging → Pre-Production → Production

• Staging — internal testing environment, mirrors production
• Pre-production — final check before going live
• Production — live environment used by end users

Typical CI/CD pipeline flow:

Developer pushes code to GitHub
        ↓
GitHub Action triggered automatically
        ↓
Unit tests run automatically
        ↓ (if tests pass)
Code compiled / built
        ↓
Application uploaded to EC2 instance
        ↓
Server / service restarted automatically
        ↓
Updated features live for users

Infrastructure as Code (IaC):

• Terraform — define your cloud infrastructure (EC2 instances, security groups, OS type) as code rather than clicking through the AWS Console
• Makes infrastructure reproducible, version-controlled, and consistent across environments

4. Lab 134 — DevOps Tools Research

Task: Pick one tool from the list, research it, and answer the provided questions.

Monitoring tools:

• Nagios
• Prometheus
• Grafana

Build, Test & Deployment tools:

• Jenkins
• Docker
• Kubernetes

How to complete: Use Google, Gemini, or ChatGPT to research your chosen tool. Answer the lab questions and submit — no presentation required.

5. AWS CLF-C02 Relevance

The following content from today's lecture is directly relevant to the AWS Certified Cloud Practitioner (CLF-C02) exam:

✅ Relevant Topics

⚠️ Partially Relevant

📌 AWS Services to Study Alongside Today's Topics

6. Key Takeaways & Tips

• Read the stack trace carefully — it tells you the file, function, and exact line of the error
• Use the debugger over print statements for complex bugs, but print statements are fine for quick checks
• Write small, single-purpose functions — this makes code testable and readable
• Smelly code is workable but dangerous — it increases maintenance cost and makes bugs harder to find
• DevOps is a culture, not just a tool — it requires cooperation across Dev, QA, DB, and Infrastructure teams
• CI/CD automates the repetitive parts of the software lifecycle so developers can focus on writing features

Notes compiled from — May 21, 2026 session. Next session: Sunday (Python practice, all day, 9 AM–6 PM). Monday: Database module (MySQL).