In reference to the recent announcement of a Service Pack 3 for SQL Server 2005 I wanted to take some time and elaborate a bit over a modified development approach we’ll be taking for SQL Server Servicing releases. With our recent SP3 announcement we will be expanding the Incremental Servicing Model to now include Service Packs and we will pursue the following objectives:
· Smaller Service Packs which will be easier to deploy
· Higher quality of Service Pack releases due to reduced change introduced
· Predictable Service Pack scheduling to allow for better customer test scheduling and deployment planning.
To set the framework let me define some of the terminology we use in the SQL Server Servicing world. A good write up of ISM concepts can be found here: http://support.microsoft.com/kb/935897 . From a high level perspective servicing a released product provides the following release vehicles:
· GDRs (General Distribution Releases)
· Hotfixes
· CU (Cumulative Update)
· Services Packs
GDR (General Distribution Release): A GDR is typically associated with a critical patch release the product groups feels should be provided to and installed by the whole customer base. GDRs are often associated with security releases, or other critical fixes needed to mitigate a problem the majority of customers will experience when using our product.
Hotfixes: As the term indicates, these are fixes coming “hot” from the development team, typically targeted at one particular customer in response to a product issue identified in a mission critical production environment. I’ve been with the SQL Server team in Redmond since 1996 and we’ve always delivered hotfix releases to our customers. Volume of hotfixes has grown steadily as our installed base as well as supported code base grew. Hotfixes cause a steady cycle of development, inclusion of a fix into the target source branch, a product build followed by a basic test pass to ensure the integrity of the product has not been compromised and the patch will address the customer issue at hand. Hotfix patches are released to individual customers through our support organization after a short test pass within the development group.
CU (Cumulative Update): SQL Server introduced Cumulative Updates about a year ago. While the product group still retains the ability to release hotfixes as customer need arises (i.e. Critical On Demand releases) it has become obvious that executing the “hotfix” development cycle too often creates inefficiencies as well as imposes quality risk due to the repeated quick development and test passes against our established code lines. The introduction of Cumulative Updates creates efficiencies and customer predictability, as well as mitigates quality risks. Cumulative Updates (rollups of individual hotfixes we would otherwise release individually) enables us to deliver a set of fixes to our customers on a very predictable 8 week release schedule. Applying incremental regression testing throughout the development cycle followed by 2 weeks of focused testing within the 8 week release window, the quality assurance processes associates with CUs exceeds those of individual hotfixes. We publicly announce the availability of CUs. So far those CUs have been available by contacting the Support organization. Based on customer feedback and strong demand we have changed this by now providing customers the ability to obtain those CUs through a web self service after a short email registration with our support services team.
Service Packs: To date we have delivered two major Service Packs for SQL Server 2005. Both Service Packs introduced major change, many of you will still be aware that Database Mirroring, a marquee feature of the SQL Server 2005 release, was only commercially supported with Service Pack 1. Customers and MVPs have given us loud and clear feedback that they desire smaller Servicing updates at high quality. By expanding ISM to now include Service Packs we will accomplish this. Moving forward we strive towards a reduction of Service Pack scope to include the following (exceptions can apply but the revised development philosophy will become obvious):
· A rollup of all hotfix work done against the software branch to date. This can be viewed as taking the work delivered through the last CU and add incremental work required in terms of packaging/installers, localization, test etc. to make it a broad, publicly available Service Pack.
· Critical fixes to issues we receive through our Microsoft customer feedback platform which enables every customer to send product issues or suggestions straight into the development organization. This includes feedback we receive through Watson error reporting as well as feedback nominated and voted for through MS Connect. As a development organization we review customer issues and votes on a regular basis.
· Issues our support organization feels need to get addressed. The most common metric applied for triage of those items are customer call volume and satisfaction scores.
Service Packs in the ISM framework will be made available for download on the Microsoft Download center to all customers just like previous Service Packs. Those Service Packs will go through the same rigorous test cycles as previous Service Packs, including making pre-releases available to customers and us doing production deployments internally at Microsoft as well as externally with customers to establish robustness proof points for release. In terms of Service Pack appearance our objective is that nothing changes for customers. However we envision that smaller Service Packs will be easier to deploy for customers due to the reduced churn introduced. Deployment planning will be easier for customers as we announce Service Packs well in advance.
So why do we believe we can succeed in smaller scoped Service Packs as described above? The recipe is SES, the SQL Engineering System introduced after the SQL Server 2005 release. If you are interested, I will elaborate on this in a future blog posting J
Matthias Berndt
Principal Group Program Manager