Part 4: Deployment, Quality & Scenarios

1. Modern Production Deployment Strategies

Deploying software to production introduces operational risk. Modern teams minimize this risk using specific rollout patterns rather than taking systems offline completely.

Blue-Green Deployment (Instant Switch):
[Router] ──> [Blue Environment (Active Production: v1.0)]
                 [Green Environment (Idle Staging: v2.0)]
                 
*Router changes path instantly to Green when testing passes.*

Canary Deployment (Phased Rollout):
[Router] ─── (90% Traffic) ───> [Production Clusters: v1.0]
         └─── (10% Traffic) ───> [Canary Instance: v2.0]

• Blue-Green Deployment:

• Mechanism: Two identical hardware environments are maintained. “Blue” hosts active live traffic (v1.0), while “Green” receives the new deployment (v2.0). Once smoke testing passes on Green, the router instantly switches all inbound traffic to Green.

• Rollback Strategy: If a production failure occurs, the router immediately switches traffic back to Blue. It offers zero-downtime and instantaneous rollbacks.

• Canary Deployment:

• Mechanism: The application upgrade is deployed to a small fraction (e.g., 5–10%) of the live production servers. Only a tiny slice of real users hit the new version.

• Rollback Strategy: Infrastructure tools monitor error rates, latency, and system load on the canary servers. If anomalies occur, traffic is routed away from the canary, protecting 90%+ of the user base from the bug.

• Rolling Deployment:

• Mechanism: Instances within a production cluster are upgraded progressively in batches (e.g., 2 servers at a time out of 10) until all instances run the new version. It avoids total environment duplication but requires backward compatibility across versions during the rollout window.

---

2. Post-Implementation: The 4 Types of Software Maintenance

Once software is live in production, it enters the maintenance phase. Software engineering defines exactly four types of support work.

Maintenance Type	Core Objective	Example Scenario
Corrective	Fixing observed bugs, failures, and operational errors reported by live users.	Patching an unhandled edge case causing a checkout crash.
Adaptive	Modifying software to maintain compatibility with shifting external environments.	Upgrading code to support a new OS update or a third-party API version change.
Perfective	Enhancing existing performance, maintainability, execution speed, or user interfaces.	Refactoring code to reduce query load times from 2 seconds to 400 milliseconds.
Preventive	Identifying and resolving latent issues before they turn into active failures.	Updating outdated third-party open-source libraries with known security vulnerabilities.

---

3. Playbook for Tricky & Scenario-Based Interview Questions

Interviews for mid-to-senior positions challenge you with situations where there is no clean text-book answer. Use these architectural framing strategies to deliver structured, pragmatic answers.

Scenario A: Handling Mid-Project Requirement Changes or Scope Creep

Question: “The client wants to add a major feature or change requirements right in the middle of development. How do you respond?”

• The Framework: Empathize ➔ Analyze ➔ Impact ➔ Decide
• The Answer Structure:

1. “I never reject a change out of hand, because software must ultimately deliver real business value. However, I protect project stability by introducing structure.”
2. If Agile/Scrum: “I explain to the Product Owner that the current sprint scope is locked to protect team focus. We immediately ingest the new requirement into the Product Backlog, refine it, and prioritize it for the next sprint planning session, shifting lower-priority stories down.”
3. If Waterfall/Fixed-Price: “I initiate our formal Change Control Process. I run an Impact Analysis to evaluate how this new feature changes our budget, timeline, and resource allocation. I present the data clearly to the stakeholders: ‘We can absolutely include this feature, but it will extend the deadline by 3 weeks and require a $15,000 budget adjustment.’ The choice rests with them.”

Scenario B: Resolving Conflicts Between Dev and QA Teams

Question: “A developer rejects a bug reported by QA, saying ‘It works on my machine.’ How do you step in and resolve this?”

• The Framework: Objective Data over Subjective Opinions
• The Answer Structure:

1. “I shift the conversation away from opinions and focus entirely on reproducible technical data.”
2. “I ensure the QA engineer has logged the defect with clear preconditions, explicit environment details (browser version, OS, DB state), and execution logs.”
3. “If the conflict persists, I facilitate a brief screen-share sync between the two. Usually, the issue stems from an environmental discrepancy—like a localized database configuration, an uncommitted configuration file, or a cached front-end build. We align the testing environment with production configurations to resolve the root cause.”

Scenario C: Deciding Whether to Deploy with Known Defects

Question: “A project deadline is tomorrow, and QA discovers bugs. Do you release it or delay?”

• The Framework: Risk Severity Matrix
• The Answer Structure:

1. “The decision depends entirely on the Severity and Priority of the remaining open bugs.”
2. “If the bugs are Blockers or High Severity (e.g., data corruption risks, security vulnerabilities, or broken primary flows), I will refuse the deployment. The cost of a production failure is far greater than the reputational hit of a brief delay.”
3. “If the bugs are Low Severity (e.g., cosmetic styling issues or minor functional workarounds on secondary paths), I collaborate with the Product Owner to document the issues as ‘Known Defects.’ We release on time, publish temporary release notes or workarounds if necessary, and immediately queue the bug fixes into the next hotfix release or the upcoming sprint backlog.”

Scenario D: The Tricky Question — “Which SDLC Model is the Best?”

Question: “If you had to pick one, which SDLC model is the best one to use?”

• The Trap: Picking Agile because it’s popular, or Waterfall because it’s structured.
• The Answer Structure:

1. “There is no single ‘best’ SDLC model. Any model becomes a liability if it is mismatched to the project’s risk profile, team structure, and requirement stability.”
2. “Agile/Scrum is excellent when market speed and adaptability are critical and requirements are fluid. However, Waterfall remains the superior choice for highly regulated, fixed-scope projects with zero room for ambiguity, such as medical device software or aerospace control systems.”
3. “The best engineer selects the model based on the problem, rather than forcing the problem to fit a preferred framework.”

---

4. Final Review Checklist for SDLC Interviews

Before heading into your interview, make sure you can answer these five final core questions using the concepts from all 4 parts of this guide:

1. Can you explain the conceptual difference between Verification and Validation using the V-Model?
2. What structural criteria make an Agile User Story high quality? (INVEST criteria).
3. Why is a Requirements Traceability Matrix (RTM) used to prevent gold-plating?
4. How does a Canary deployment differ from a Blue-Green deployment in terms of target resource requirements?
5. What distinguishes a bug’s Severity from its business Priority?

---

5. Software Quality: QA vs QC & CMMI

• Quality Assurance (QA): process-oriented — defines and enforces the processes/standards that prevent defects (audits, process improvement, reviews). Proactive.
• Quality Control (QC): product-oriented — actually detects defects in the built product (testing, inspection). Reactive.
• One-liner: QA is about the process (“we build it right”); QC is about the product (“the product is right”).

CMMI Maturity Levels

The Capability Maturity Model Integration rates an org’s process maturity on a 1–5 scale:

Level	Name	Meaning
1	Initial	Ad-hoc, unpredictable processes
2	Managed	Processes planned and tracked per project
3	Defined	Standard processes documented and followed org-wide
4	Quantitatively Managed	Processes measured and controlled with metrics
5	Optimizing	Continuous process improvement

• ISO 9001: an international standard for a quality management system (QMS) — certification shows the org follows documented quality processes.
• Six Sigma: a data-driven methodology (DMAIC: Define, Measure, Analyze, Improve, Control) targeting defect reduction to ~3.4 defects per million.

6. Maintenance Types

The four standard types (from the IEEE/ISO taxonomy):

• Corrective: fixing defects/bugs found after release.

• Adaptive: modifying the software to cope with environment changes (new OS, new hardware, new laws).

• Perfective: adding/improving features and performance for user needs.

• Preventive: making changes to prevent future problems (refactoring, updating documentation, improving maintainability).

• Rule of thumb: corrective = fix what’s broken; adaptive = keep up with change; perfective = make it better; preventive = stop future breakage. Maintenance typically costs the most of any SDLC phase.