Hey everyone, today I want to give you an inside look at how your feature requests and bug reports make their way into the apps and websites you use every day. I'm San, co-author of best-selling system design interview books. We make complex system design concepts easy to understand through clear animations.
Let's get started. Shipping code all starts with the product team gathering user feedback and requirements. The product and engineering teams break this down into smaller work items or user stories. Developers then pick up items during sprint planning meetings.
A sprint is typically one to two weeks long. For larger projects, work may carry over multiple sprints. Engineering managers or tech leads prioritize and sequence items across sprints to balance team capacity.
Once the sprint is planned, developers start building. For larger initiatives, there is often an RFC or design document process to align on high-level architecture and technical approach up front. Here's where some key processes come into play.
Developers use Git or something similar for source control and create feature branches to build new functionality with Dell impacting the main codebase. This isolates their work. If database schema changes are required, migration scripts are developed in branches as well.
Schema migrations require thoughtful design and extensive testing due to the risk of data corruption. Once the code is ready, they open a pull request for the team to review. This knowledge sharing catches issues early. After approval, It gets merged into the main branch after running comprehensive unit tests.
These tests help catch bugs early. Once a feature lands in the main branch, it kickstarts the CI-CD pipeline. Tools like GitHub Actions and Jenkins automatically builds, tests, and deploys the code through multiple environments like dev, tests, and staging. Now validating across environments is crucial.
Staging should match production infrastructure for consistent validation. This reduces surprises down the line. QA engineers thoroughly validate functionality, run regressions, security scans, performance tests, and much more.
It's worth noting that some teams rely on developers to validate their own code instead of dedicated QA. It works for some products, but not all. When the bill passes all checks, it goes into UAT.
UAT stands for User Acceptance Testing. The product team, QA, and developers all validate the features together. Release candidates step past UAT, proceed slowly to production.
Some teams use techniques like canary releases and feature flags to slowly roll out changes to reduce risk. For production rollout of schema changes, techniques like maintenance windows, read replicas, and rollback scripts reduce risk. Multi-phase migrations and feature flags help control access during the transition. Throughout the process, SREs monitor metrics, logs, and traffic for any production issues.
Bugs get prioritized and fixed. In addition, Product and engineering teams also monitor analytics to make sure the feature works as expected and does not hurt key business metrics. So in summary, your feature request takes a journey through design, development, testing, and incremental rollout before becoming part of the software you use every day. If you like our videos, you might like our system design newsletter as well.
It covers topics and trends in raw-scale system design, trusted by 500,000 readers. Subscribe at blog.bybygo.com