QA Process for a ConfigMgr 2012 "Application Factory," Part 1

For my first series of posts I plan to present a number of posts that contain both technical and process details, as I described as the purpose for this blog.

As consultants and IT professionals we are often asked to implement new technologies or new features of existing systems that are already deployed. The easiest part of these types of engagements is the actual deployment of the new capabilities or technologies. The challenge for the IT professionals performing these implementations is to ensure the long-term success of the effort by:

• Defining what new processes are needed to support the new technologies

• Identifying existing processes that will need to be modified to accommodate the new process requirements to support the new technology

• Informing the customer of the required changes and creating working groups with the knowledge of existing processes, and authority to make the necessary changes to those processes

• Document, in fine detail, the new and/or modified processes

• Brief and/or train all people involved on the changes and answer any questions

The focus of this series is to provide a quality assurance process for an application packaging and deployment workflow in a new deployment of System Center Configuration Manager 2012 (ConfigMgr). 

There are already many excellent resources available for IT professionals on how to plan, design and implement ConfigMgr environments and this series will not duplicate any of that fine work.

This document will focus on processes that support a common requirement for application deployments with ConfigMgr. Also, please understand that the examples given in this series are just that—examples. Every enterprise has existing processes to implement and maintain the IT services that support the business drivers of their enterprise. The examples given this series are based on experiences with such an entity possessing fairly mature processes in their application packaging processes. But the infrastructure modernization effort necessitates changes to those processes in order to accommodate changing requirements.

This series is going to use the famous company, Contoso, as the customer who has decided to implement System Center Configuration Manager 2012 (ConfigMgr) environment to deploy and manage the many applications for its workforce. ConfigMgr is being deployed to replace its legacy application management and deployment environment, so they already have an experienced team of application packagers and administrators for their legacy system.

Contoso has decided adopt a SharePoint workflow process called Client Lifecycle Enterprise Management (CLEM), developed by Andrew Lockwood of Microsoft Consulting Services. While CLEM is used as the workflow process framework for this series, organizations may already have workflow processes that can be modified to accommodate the new types of process being discussed in this series.

1          Summary

The Contoso Corporation (Contoso) has made the strategic decision to implement an OS and  application deployment modernization project. The scope of the deployment modernization includes the introduction of Microsoft System Center 2012 Configuration Manager (ConfigMgr) into the Contoso production environment. In addition to ConfigMgr, the modernization project also necessitates the introduction of new processes that will allow Contoso to realize the full benefit of the new technological capabilities that ConfigMgr brings to the organization.

To support these new processes a SharePoint-based workflow management site has been implemented to allow Contoso to manage and track an application’s lifecycle as it moves into the Contoso environment, from proposal to retirement. This tool is called Client Lifecycle Enterprise Management (CLEM). The workflow that CLEM follows includes the following phases:

• Entry: The application owner enters information about the application into the CLEM website for submission and approval for the application to move through the lifecycle process for Contoso’s application management

• Request Validation (Phase 0): CLEM generates an email to a designated validator whose job it is to ensure the completeness of the data entered by the application owner

• Package Approval (Phase 1): The Contoso-designated approver reviews that report from the request validation phase and either approves or disapproves the request.

• Package Assignment (Phase 2): The packaging team lead(s) review each incoming request and assign the packaging task to a team member based on skillset and availability

• Application Packaging (Phase 3): Packaging team members package or sequence (for App-V) each application for silent installation and deployment via System Center 2012 Configuration Manager (ConfigMgr). The packager is responsible to create a RECIPE.TXT file that will be used by the QA and ConfigMgr administrative personnel to create the application in ConfigMgr for testing and deployment

• Packaging Quality Assurance (QA) Process (Phase 4): The QA process is a multi-disciplined process that ensures the consistency of the quality of applications prior to entering the production phase of their lifecycle. This includes normalizing naming conventions; adding the application to ConfigMgr using the administrative console; distributing & deploying  application to QA target test systems; performing install tests & often troubleshooting issues in deployment; basic functionality (smoke) tests; documenting test results and troubleshooting activities

• Owner Sign Off (aka User Acceptance Testing (UAT)) (Phase 5): A coordinated effort among QA and ConfigMgr administrators along with application owners, application subject matter experts (SME), and test users.

• Deployment (Phase 6): After an application has completed all previous steps it is ready for deployment in the production environment.

• Retirement or Rejection: Every application eventually completes its lifecycle and is retired. Some applications fall short of the standards for Contoso and are rejected. Both of these require appropriate documentation within the application lifecycle management system.

The focus of this document is to describe the process in phases 4 and 5, QA and UAT, from the preceding list.

1.1            Document structure

The document is laid out in a manner that will work the reader through the QA process from the time an item hits the QA queue in CLEM (phase 4), through Owner Sign-off (phase 5) and then to production (phase 6). Alternatively, an application that does not meet QA verification may also be routed back to Packaging (phase 3) or to Rejection, where it never gets deployed into the Contoso environment.

 The following list lays out the overall document structure:

• 1 Summary

• 2 Initial QA intake validation

• 3 Application creation in Configuration Manager (ConfigMgr) for App-V

• 4 Application creation in ConfigMgr for MSI installs

• 5 Application creation in ConfigMgr for script installs

• 6 ConfigMgr application property modifications

• 7 Distribute and deploy application in ConfigMgr

• 8 QA testing on client systems

• 9 Post QA process for UAT and production

• 10 UAT processes

• 11 Troubleshooting examples

1.2            Overview:

This document provides a high-level overview of the process to move an application through the testing process in the Deployment Modernization project at the Contoso Corporation (Contoso).

The process includes:

• Intake QA process

• Adding, configuring, distributing and deploying the application in the Configuration Manager 2012 administrative console

• Testing the application on a VM

• Recording and documenting the test results.

• Routing the application in CLEM. It can be:

• Success: Move to next phase. PreDeployment (Phase 5)

• Fail/Errors: Return to Package Assignment (Phase 2)

• ConfigMgr issues: keep in Testing (Phase 4), but request assistance from ConfigMgr infrastructure team

• Managing application in ConfigMgr and routing application in CLEM

• UAT processes and communications

1.3            QA process workflow

The following diagram provides a high-level workflow of the QA process as it relates to function and the document structure.

Figure 1: QA Process Workflow

Table 1: Lifecycle path for application source files at Contoso

[Coming Next: Part 2: Initial QA Intake Validation}