This is #3 in a very long series of posts on Stack Overflow’s architecture.Previous post (#2): Stack Overflow: The Hardware - 2016 Edition
We’ve talked about Stack Overflow’s architecture and the hardware behind it. The next most requested topic was Deployment. How do we get code a developer (or some random stranger) writes into production? Let’s break it down. Keep in mind that we’re talking about deploying Stack Overflow for the example, but most of our projects follow almost an identical pattern to deploy a website or a service.
I’m going ahead and inserting a set of section links here because this post got a bit long with all of the bits that need an explanation:
Source & Context
The Human Steps
Branches
Git On-Premises
The Build System
Step 3: Finding Moonspeak (Translation)
Step 4: Translation Dump (JavaScript Edition)
Step 6: Translation Dump (C# Edition)
Step 7: Importing English Strings
Tiers
Database Migrations
Localization/Translations (Moonspeak)
Building Without Breaking
Extra resources because I love you all
insightful comments on HN. Here’s one from taurath
How people manage git and source control tells you a lot of things about a company's culture. They said that most commits go directly onto master and this works for them, which indicates:
- Good rapid communication about who is working where. People are generally not touching the same code or else you'd run into frequent collisions (solvable via rebasing of course but they would be doing more branching if it were a thing to happen very frequently I'd suspect)
- The developers are given autonomy and have assumed some level of mastery over whatever their domain is. Trust in each developer's ability to commit well-formed and considered code.
- They have a comprehensive test stack, which helps verify the above point and keep it sane
