Decrypting the SQL Server database system compilation

Do you know how a large enterprise database server product of SQL Server is created?

Here are some related data:

The size of each build is around 300GB.

Each complete build requires dozens of high-end servers to run for 2.5 days.

Each complete build consists of thousands of jobs and more than 10,000 parameters.

We do 20 or so builds a day, 130 a week.

The build team at Microsoft headquarters in Redmond and Beijing will be able to guarantee a 24-hour uninterrupted smooth build.

Since last year, our build team has successfully completed thousands of builds on time.

Perhaps you will ask: "Why is your build so big?" Why does it take such a long time? Why do you have to do so many builds every day?

Why is one of our builds so big? For example, your 32-bit Chinese retail development version of SQL Server DVD, including tools and help documentation is 4GB, then you can estimate: First add some internal build information and statistics, and for debug symbol, then multiply by 2 (Retail edition, Debug version), multiplied by 3 (CPU type: x86, x64, and IA64), multiplied by the number of versions (enterprise, development, standard, etc.), multiplied by the number of supported languages. More than 1 TB, right? J Fortunately, the SQL 2008 Setup team adopted the consolidated Setup mode, so that in a language pack, the installer can determine your CPU type and automatically install the corresponding version according to the serial number you enter. That's how our build was compressed to 300GB.

Why do we have a build that takes so long? It is an extremely complex process to build such a large enterprise database server product, and the SQL Server build system is already one of the most efficient systems in Microsoft. She is a graphical user interface and highly automated. After 60 hours, most builds will automatically complete and notify the person of the status and information of their build. If the build fails, it also provides a detailed error message for Debug. SQL Server's build system is not only so easy-to-use and efficient, but also flexible enough to accommodate specific requirements and build workflows. The SQL Server build system is driven by Windows Workflow Foundation, and thousands of jobs are distributed in parallel or serially to dozens of build machines and complete. The build process includes:

Synchronize dozens of GB of source files and related required files and resources to build machine

source Code Static Analysis

Compile all executables and test files and sign

Build system Database

Optimization

Localization

Make installation files and install packages and sign them

Index symbol and source files

How many builds we do every day is a reflection of how we support the entire SQL Server engineering system and architecture:

The first thing to declare is that we are always providing support for multiple products, such as the current SQL Server 2005 and the upcoming SQL Server 2008.

In the engineering architecture and architecture of SQL Server 2008, we make a separate branch of each feature feature that needs to be added or enhanced, and after this feature development and testing is complete, the code is merged into the main line of SQL Server code. Therefore, depending on the priority and size of the functional features, SQL Server is divided into dozens of different teams, each consisting of architects, project managers, development and testers, help and case documentation specialists, and even scientists and researchers. Each branch needs a build to be tested in time, so we have this--130 of the number of builds we need each week. When the build is finished, the test Execution team and its branch teams perform automated tests to ensure that the quality of their code meets stringent requirements and standards. Finally, when this feature development and testing is complete, the code will be incorporated into the main line of SQL Server code, and then the other branch teams will regain the mainline code and fuse the current code of its branches to ensure synchronization with the mainline code.

So how do you ensure that the code quality of the mainline always conforms to stringent requirements and standards? We will reveal another magical field in subsequent articles, see you next time!