Release Management. ITSM ServiceNow User Guide. November, 2013

Transcription

1 Release Management ITSM ServiceNow User Guide November, 2013 Contact:

2 Document Change Control VERSION DATE AUTHOR(S) BRIEF DESCRIPTION 0.1 9/18/13 J.Worthington Initial Draft; TOC for review 0.2 9/25/13 J.Worthington Draft for ML/RL review /14/13 J.Worthington GoogleDocs draft /18/13 J.Worthington/V.Aisner User Review Draft /29/2014 J.Worthington/V.Aisner User Review Draft Updates /1/13 J.Worthington Diagram edits /4/13 V.Aisner Basic edits /25/13 V.Aisner Content Updates Draft Page 2 of 2

3 Table of Contents 1 Introduction... 5 How this manual is structured... 5 Who should use this manual Overview... 6 Key Release Management Policies... 6 The Three R's of Release Management in ServiceNow Records, Roles and Releases Working with Product Records Creating a New Product Record Editing a Product Record Working with Release Records Release Planning Release Status Management Working with Feature Records Drafting a Feature for Release From Development to Stage From Stage to Production From Production to Close Enhancements / Defect Corrections Feature Upgrade / Patch Feature Configuration Feature Back End Data Change Feature Monthly Reporting Other Feature record information Working with Issues (Bugs) Working with Task Records General Information Deployment Tasks Querying and Reporting Creating an ad hoc Query Using Filters APPENDIX The Application Navigator Dashboards & Overview Pages Creating and Using Feature Templates ServiceNow User Administration Default Notifications Figure 1: ServiceNow record relationships... 7 Table 1: ServiceNow Roles... 7 Figure 2: ServiceNow Release and Feature record status... 9 Table 2: Release and Feature Status Interplay Figure 3: Product List form Figure 4: Product record Figure 5: Edit Members Form Figure 6: Release Form List in Releases Tab Figure 7: Release List form Figure 8: Release form Figure 9: Schedule tab Figure 10: The Product Groups tab Figure 11: The Features tab Figure 12: Edit Members form Page 3 of 3

4 Figure 14: Release Approvers tab related list Figure 15: Approval record Table 3: Release Status Management Figure 16: Feature list form Figure 17: Feature form Figure 18: Documentation Tab on Feature form Figure 19: Impact Implications Tab on Feature form Figure 20: Affected CIs Tab on Feature form Figure 21: Feature record (Ready for P-1 status) Figure 22: Approval record (Feature) Figure 23: Feature record (Ready for Production status) Figure 24: CI needs updating checkbox (Task record) Figure 25: Enhancements/Defect Corrections workflow Figure 26: Upgrades/Patches workflow Figure 27: Configuration workflow Figure 28: Back-End Data Change workflow Figure 29: Monthly Reporting workflow Table 4: Feature Status Management Figure 30: Notes tab Figure 31: External Tickets tab Figure 32: Deployment Plan tab Figure 33: Issues related list (from Application Navigator) Figure 34: Issues related list (Feature record) Figure 35: Issue record Figure 36: Dependent Features tab Figure 37: Task list form (from Application Navigator) Figure 38: Task list form (from Feature record) Figure 39: New Release Task form Figure 40: Percent complete progress bar (Feature Tasks related list) Figure 41: Release Deployment Task Figure 42: Affected CIs related list Figure 43: CI asset form Figure 44: Releases list form (filtering) Figure 45: Reports module (View/Run) Figure 46: Sample Report form Figure 47: Schedule of Reports Figure 48: Exporting Form Data Figure 49: Exporting List Data Figure 50: Release menu in the Application Navigator Figure 51: Overview Dashboard Figure 52: Feature Templates (Application Navigator) Figure 53: Feature Templates list form Figure 54: Feature Template form Figure 55: Delegates (Application Navigator) Figure 56: Delegate form Table 4: Default notifications Page 4 of 4

5 1 Introduction This User Manual was prepared for the HUIT Release Management process, version x.x dated yy/zz/aaa, which can be found at <link>. Manuals for ITSM processes provide users with a guide to the current HUIT process, associated policies and supporting technologies. Changes to this manual are summarized in the document change control at the front of the document, and will highlight changes to the process and tool that may address new capabilities as a result of: Supporting technology upgrades and revisions; Process enhancements and changes; Related ITSM process implementation and integration. Questions, concerns and feedback about this document should be addressed to: ITSM@harvard.edu How this manual is structured This manual follows the HUIT Release Management process. Based on the ITIL framework, this process reenforces industry best practice, allows for the introduction of related processes and improvements over time, and is consistent with supporting technologies such as ServiceNow. Who should use this manual This manual is not intended for people without direct access to ServiceNow. Because the manual covers the entire Release Management process, most product and practice management staff should become familiar with its contents. Each chapter covers major activities in the process, and most participants may be involved in these activities at any particular time. The Overview provides information about key release management policies and a summary of records, roles and releases in HUIT's release management process. If you are new to using ServiceNow, consider signing up for ServiceNow User Training Page 5 of 5

6 2 Overview Key Release Management Policies 1. All in-scope product and practice teams will use ServiceNow for the Release Management process. However, JIRA may be used to manage the build and test phase. This phase includes capturing requirements, documenting functional and technical specifications, developing and testing up to, but not including, testing in the P-1 environment. 2. Release activity and configuration items (CIs) comply with Harvard's Information Security policy. 3. All Financially significant release requirements for signoffs and significant control points reside in ServiceNow. 4. An Emergency Release can only be used to address a production outage (e.g. major incident, regulatory requirement, security incident). 5. An Exception Release is an out of cycle release, and the business must submit a business case for approval. 6. The major number of a release version is updated for platform changes and the minor number for each release. 7. Features must be tested and signed off before they are deployed in P-1 and Production. 8. Releases must be approved by the Product Manager, the Practice Manager and the Release Manager before they are deployed into P-1 or Production, and must be installed by deployment teams separate to the technical contact in line with the audit requirement for separation of duties. 9. Release Management will inform Change Management of scheduled deployments into Production. 10. Change Management is the authority for approving updates to the Configuration Management Data Base (CMDB). However, Change Management delegates the responsibility of updating the CIs affected by a Release as well as the responsibility for validating those updates to the Release Management process. 11. If a Feature is dependent on other features, it must be documented on the Dependent Features tab. 12. The Release Management process shall comply with Harvard's policies and procedures for IT controls and governance. The Three R's of Release Management in ServiceNow Records, Roles and Releases Records A release is the vehicle for moving changes to an application and its infrastructure from development to production through an orderly process. A product and features comprise every release. A product represents a portfolio of applications that defines a release and circumscribes the changes that it can include. Features capture the changes to a product to be deployed and are assigned to a release based on priority of the change and the schedule for the release. Features may be opened but not assigned as a tool for planning. Tasks for specific actions to be taken are created automatically based on the workflow associated with a feature type and must be completed or cancelled for the next step in the process to be taken. Some tasks are optional and require selection via a checkbox. Page 6 of 6

7 The figure below illustrates the record relationships in ServiceNow. Figure 1: ServiceNow record relationships Roles Roles in ServiceNow determine the capabilities that users have through permissions and corresponding process roles. Release Management supports two roles Release Admin and Release User. The table below provides a summary of the groups in each role by process and associated capabilities by permissions. ServiceNow Role Process Role ServiceNow Permissions Release User Practice group members Product group members Data Base Administrators System Administrators View Product and Release records Create/Update Feature records (with exception of Affected CIs tab) Create/Update Issue records Create/Update Task records Release Admin Release Managers Create/Update Product record Create/Update Release record Create/Update Feature records Add/ Edit CIs on the Affected CIs tab Assign Deployment Tasks to deployment groups (Sys Admin, DBA) Add/Remove Features to Release after 'In P 1' status or later Approve Feature Approve a Release All Release User permissions Table 1: ServiceNow Roles Release managers establish the products that come under the release management process by creating a product records in ServiceNow. The record stores information required for managing a release including the practice and product groups and the release manager associated with the product. The record also provides a list of releases for the product and their statuses with capabilities for drilling down to the features in a release. Release managers set up a release version for a product by creating a release record in ServiceNow. The record establishes the relationship between the product and the release and enables release managers to record the dates Page 7 of 7

8 for each phase from development through stabilization. As the release progresses, additional information becomes available on the record through tabs for features, approvers and tasks for the release itself. A bar at the head of the record highlights the current status of the release as a whole. The interplay between release phase and feature records determines the status. Features are the province of product, practice, release and infrastructure groups. They represent the individual changes to a product and become, therefore, the building blocks of a release. Features encompass the range of change types that typically comprise a release from enhancements and defect corrections, to patches and upgrades, to configuration updates. The feature record uses type to enable these distinctions. The type also drives differences in workflows and associated tasks that may be required to implement a feature. Product and practice groups generally enter features for changes to the application itself and release managers to components of its infrastructure. The status of a feature record indicates where it stands within an environment and within the release cycle. Releases Releases follow the basic Release Management process flow based on the timeline for the release. Both release and feature records change status as they move through the phases of the release by either pre-defined workflows or by specific buttons at the top of the Release or Feature forms. Tasks may be created automatically based on the workflow associated with different Feature Types. Some tasks are optional and require selection by the user via a checkbox. Figure 2 below illustrates the phases and associated statuses. Page 8 of 8

9 Release Management Process Phases Release Planning P 3 Development P 2 QA / Test P 1 Test/Stage for Production PRODUCTION Release Record Status IN PLANNING IN DEVELOPMENT IN QA / TEST AWAITING P 1 APPROVAL READY FOR P 1 IN P 1 AWAITING PROD APPROVAL READY FOR PROD IN PROD CLOSED Release Approval required Release Approval required Feature Record Status DRAFT ANALYSIS & DESIGN IN DEVELOPMENT READY FOR P 2 IN P 2 READY FOR P 1 IN P 1 READY FOR PROD APPROVAL AWAITING PROD APPROVAL READY FOR PROD IN PROD CLOSED When Feature status moves past DRAFT, Tasks are automatically created. The Feature MUST be associated with a Release in order to move to P 2. Release Approval required Feature Approval required Figure 2: ServiceNow Release and Feature record status Page 9 of 9

10 Release Planning incorporates activities that can start in advance of the deployment process. Release managers open new release records for future product releases to facilitate collaboration between product and practice managers. Together they set priorities and schedule deployments of features to production by establishing dates for the release cycle. Features can be created at any time and will automatically be in status, but planning for features starts formally with a status update on the record to. Product and practice managers then have the option to create tasks for creating requirements, specifications and test plans and thereby to determine the timing for deployment to production. The release manager signals the beginning of the Development phase in the P-3 environment by clicking the In Development button on the release form in conjunction with a due date for functional requirements under the schedule tab. Note that the date scheduled for the end of development is also available on this tab. The practice or product manager designates those features to be included in the release by clicking the In Development button on the individual feature records. The release moves out of development and into QA/Test based on the date for the start of P-2 testing in the release schedule record. The release manager notifies product and practice managers that the next phase is underway by updating the status of the release to. A feature moves to the next phase of the release only when all tasks have been completed and the release identified. The status on a feature record indicates completion of required tasks. The status shows that the feature has been assigned to a release and deployed to the P-2 environment. From here, the progress through the P-2, P-1 and Production environments in the next phases of the release follow a similar pattern deploy, approve, and stage. Release managers request approval to move features from the current environment based on the sign-off dates. All features intended for the release must have a status for approval requests to move forward. When the approvals have concluded, the status of the release changes to in synch with the features. Approvals generate tasks for installation when the date scheduled for deployment in the next environment has come Following the release to production, features are validated and closed. When all feature records have been closed or cancelled, the release manager closes the release by clicking the Closed Complete button to update the status on the release record. Release and Feature statuses are changed either by pre-defined workflows or by buttons at the top of the Release or Feature forms. Although represented as a dropdown, the status field on a record is read-only and is greyed out. The table below illustrates the interplay of statuses between the release and feature records as the release moves from one phase to the next. Release Phase Release Status Release Status Update Trigger Feature Status Feature Status Update Trigger Planning Open new Release record Open new Feature record Click button for Analysis & Design P 3 Development Click button for In Development Status update from Pending on task to develop and unit test code OR Click button for In Development Page 10 of 10

11 Release Phase Release Status Release Status Update Trigger P 2 QA/Test Click button for In QA/Test Click button for Awaiting P 1 Approval Approval of all features for release to P 1 Feature Status Feature Status Update Trigger Click button for Ready for P 2 2 Status update to Completed on task to deploy feature to P 2 Click button for Ready for P 1 P 1 Test/Stage Status update to Completed on task to deploy feature to P 1 All features for release have status Click button for Ready for Production Approval Production Postproduction Click button for Awaiting Production Approval Approval of all features for release to Production All features for release have status Click button for Close after all features validated and closed Table 2: Release and Feature Status Interplay Request for feature approval from release record Approval of all features for release to Production Status update to Completed on task to deploy feature to Production Click button for Close after all features validated and CI updated where required The User Guide will describe how to work with each type of record in ServiceNow based on the standard workflows. Review the Application Navigator section in the Appendix for options to navigate the Release Management module using the ServiceNow interface. Page 11 of 11

12 3 Working with Product Records Creating a New Product Record To create a Product record, click on Products from the Release menu on the Application Navigator. A Products list form appears. Figure 3: Product List form Click on the New button to open a blank Product form. Figure 4: Product record Mandatory fields are marked with a RED bar in the field label and must be filled in for the record to be saved. All Products require the following data: Practice group Short description Description It is important to set an appropriate value for Financial impact (default) for the product. This sets the default value in a dropdown for financially significant features under the Impact Implications tab on the feature record for a product. Current options for the default value include: Page 12 of 12

13 None Undetermined NOT Significant Significant Not Applicable Take care to reset the value on the feature record if it differs from the default on the product record to ensure that prescribed steps are followed for both financially-significant and nonfinancially-significant changes to an application in a feature. Clicking the Save button causes tabs for Product Group and Releases to appear on the record. The number displayed on each tab indicates the number of records that currently exist for the product in each area represented. Add Product Groups to the record by clicking the Edit button from the Product Group tab and using the Edit Members form to display a collection of product groups from which individual groups may be added to the product group list. Note that no option to create a new product group is available from the Product Group tab. Figure 5: Edit Members Form Add a new release to the product record by clicking the New button from the Releases tab. A blank release form will be displayed for creating the release. Figure 6: Release Form List in Releases Tab Page 13 of 13

14 To add an existing release, click the Edit button from the Releases tab and use the Edit Members form to find Releases in the Collection and to add or remove existing releases from the list displayed in the Releases List. Editing a Product Record To edit an existing product record click the Number link associated with the Product you need in the Product list form, and the product record will be displayed for editing. Note that creating or editing a product record requires Release Admin role permissions. The Release User role has view-only permissions. Page 14 of 14

15 4 Working with Release Records Release Planning To create a new Release record or to open an existing record, click on the Release menu from the Application Navigator. This brings up the Releases list form. Use the New button at the top of the form to open a new release record or click on the Number link associated with the release to open an existing record. Figure 7: Release List form For a new release, it is necessary to enter the data required for all releases. For an existing release, data for mandatory fields will have been entered and will be displayed on the form when it comes up. Figure 8: Release form Mandatory fields are marked with a RED bar in the field label and must be filled in for the record to be saved. The red bar turns green when the field contains data. All releases require the following data: Release version Product Release type Practice group Short Description Description Production start and end dates under the Schedule Tab Page 15 of 15

16 The Release version is a free-text field for naming the release. Use the naming convention for the product's release version and update the major number when there will be a platform change and set the minor number to the number of the release itself. The Product takes its data from a look-up list in ServiceNow. You can use the type-ahead functionality to find the appropriate product for the release quickly. Selection of the product will automatically populate the Release Manager field. The Release type that you enter determines the workflow and tasks associated for the feature. Three options are currently available. 1. Normal 2. Emergency 3. Exception A Normal release represents business as usual for deploying changes from development, through testing and approval to production in a scheduled release. An Emergency release is used to deploy changes that address a major production outage to the production environment. An Exception release occurs when a business group has requested an offrelease change, and the change has the approval of the Exception Board. All release types have the same workflow. The Practice group identifies the Practice responsible for the product in a release. You can use the type-ahead functionality to find the appropriate practice for the product quickly or click the magnifying glass to display the Groups list form. Select the Practice Manager from the list of developers displayed for the practice group after clicking the magnifying glass. Make the Short Description the same as the Release version. It is used to identify the release when it appears in a list. Use the Description to provide more detailed information about the release cycle. The Production start and end dates establish the scheduled dates for the release to be deployed to production. The Schedule tab also provides a convenient place for Product and Practice Managers to see the due dates for a Release as they plan their activities. Use the calendar icon to facilitate entry of the date and time. Click the icon, select the date and time and click the green arrow to enter the information. Note that the end date will default to the start date and must be updated if different. Figure 9: Schedule tab Page 16 of 16

17 ServiceNow completes fields marked with an AMBER bar. It assigns a unique number to the record in the Number field when it is first opened. The Status, while technically a dropdown, is set by buttons at the top or bottom of the form when clicked. Click the Save button at the top or bottom of the form to save the release record. Clicking the Submit button saves the release and returns you to the previously viewed page. Saving also creates a second set of tabs on the form for access to the following: Product groups Features Release approvers Release tasks The Product Groups tab displays the product groups associated with the product for the release. Note that no option to create a new product group is available from the Product Group tab. Figure 10: The Product Groups tab The Features tab provides the capability not only to view all features assigned to the release, but also to add or remove them. Clicking the tab opens a feature list form where you can add a feature through the New button. Figure 11: The Features tab The Edit button brings up the Edit Members form that enables you to add or remove existing features for the release. Figure 12: Edit Members form Page 17 of 17

18 To open an existing Feature record from the release record, click the Number link associated with the Feature you need in the Feature list form. Release Status Management The Status on a release record identifies not only the phase that the release is in, but also the particular step within the phase. Buttons on the record are used to update the status and therefore the progress of the release. They also generate new buttons for initiating subsequent statuses and tasks from one phase to the next. A chevron, highlighted in green, at the head of the release record indicates the current status of a release. Figure 13: The Release form's header The Release Manager has responsibility for updating the status of the release record as it moves through the process as well as other information as needed. Development Phase To signal that planning for a release has concluded and development of features for the release should be underway, the Release Manager clicks the In Development button to update the status from to. This action also generates two new buttons in anticipation of moving to the QA/Test phase. The schedule on the release record indicates when the development period ends and testing in the P-2 environment begins. In Q/A Testing Awaiting for P-1 Approval QA/Test Phase The release manager clicks the In Q/A Testing button to inaugurate testing in the P-2 environment. This action has no impact on the status of any feature, but all features to be included in the release should have a status of for the start of this phase and of when testing has completed and approvals can begin. The release manager can click the Awaiting for P-1 Approval button to see the status of testing. ServiceNow will display an error message that lists any features not in status as the due date for the P-2 sign-off draws near. When all features are set to go, clicking the button updates the release's status to and lists requests for approval in the Release Approvers tab. Approvers typically include the practice manager, product manager and release manager Figure 14: Release Approvers tab related list The Release Approvers can open the Approval record from the approval list form on the tab or from a gauge in their Overview/Dashboard page. The Approval record has buttons for Page 18 of 18

19 approving or rejecting deployment of all features in the P-1 environment. A rejection requires an explanation in the Comments box. Figure 15: Approval record Approval of the release updates its status to to be included in the release. and defines the package of features Test/Stage Phase Testing in the Test/Stage environment begins at the time scheduled for P-1 testing to begin on the release record. When all features in the release are in In P-1 status, the status of the release automatically changes to In P-1. A new button, Awaiting for Production Approval, displays on the release record in anticipation of the next step in the release. When the status of the release becomes In P-1, product and practice managers lose the ability to cancel a feature and must request that a release manager pull a specified feature from the release. The release manager can review the progress of testing by clicking the Awaiting for Production Approval button. ServiceNow displays an error message if any features do not have a status of Ready for Production Approval and provides a list of those where testing has not been completed. At the time scheduled on the release record for P-1 signoff, the release manager requests approvals for the release to be deployed in the production environment by clicking the Awaiting for Production Approval button. This action automatically updates the status of the feature records to. On notification, practice managers approve or reject individual features for release. Any rejection requires an explanation in the comment field on the approval record. When all approvals are in, the status of the release changes to Ready for Production and a task to deploy features in the production environment appears on the feature records with approval to move forward except for features whose type is Upgrade/Patch. Release managers identify the deployment group for installing features in the production environment and assign the task as required. Production Phase The release manager provides the deployment group with a schedule for deploying all features approved for release to production in line with the start date and time entered on the release record. Completing the production deployment automatically triggers a change in status to on the release record. When all features have been validated and Page 19 of 19

20 closed, the release manager closes the release by clicking the Close button and updating its status to. The following table provides a summary of release status management through the phases of a release from planning to close. Release Phase Release Status Status Update Trigger Planning P-3 Development Open new release record Click button for In Development P-2 QA/Test Click button for In QA Test Click button for Awaiting P-1 Approval Approval of all features for release to P-1 P-1 Test/Stage All features for release have in status Production Post-production Table 3: Release Status Management Click button for Awaiting Production Approval Approval of all features for release to Production All features for release have status Click button for Close after all features validated and closed Page 20 of 20

21 5 Working with Feature Records To open a new Feature record click on Create New Feature in the Application Navigator under Release. A blank Feature form is displayed for data entry. Alternatively, you can create a new feature from the Features tab on a Release record. (See Chapter 4, Working with Release Records) This approach will assign the feature to the release automatically. To edit an existing Feature record click on Features (All) or Features assigned to me in the Application Navigator. In the Feature list form click the Number link associated with the Feature you need to open it for editing. Figure 16: Feature list form Drafting a Feature for Release For a new feature, it is necessary to enter the data required for all Feature types. For an existing feature, data for mandatory fields will have been entered and will be displayed on the form when it comes up. Figure 17: Feature form Mandatory fields are marked with a RED bar in the field label and must be filled in for the record to be saved. The label becomes GREEN when data are entered. All Features require the following data: Type Product Technical group Functional group Page 21 of 21

22 Short description Description The Type that you enter determines the workflow and tasks associated with the feature. Seven options are currently available. 1. Enhancement 2. Defect Correction 3. Upgrade/Patch 4. Configuration 5. Application Deployment 6. Back-End Data Change 7. Monthly Reporting Enhancement, Defect Correction and Monthly Reporting are the most common feature types and are generally created by product and practice groups for changes to an application or product. The Upgrade/Patch type falls primarily to a release manager and secondarily to a practice manager for changes to an application's infrastructure. Application Deployment accommodates the use of JIRA for tracking changes during development. A Back-End Data Change feature is typically free-standing and not associated with a release. The Product, Technical group and Functional group fields take their data from look-up lists in ServiceNow. You can use the type-ahead functionality to find the appropriate product or group for the feature quickly. The Short Description helps to identify a feature when it appears in a list. Make it brief, but descriptive. The Description provides a more detailed explanation of the change the feature represents and facilitates a quick review of the contents of a release. ServiceNow completes fields marked with an AMBER bar. It assigns a unique number to the record in the Number field when it is first opened. The Status, while technically a dropdown, is set by buttons at the top or bottom of the form when clicked. Release remains blank until the feature is associated with a specific release or is opened from the Release form. Only release managers can update the release on a feature after it has been deployed to the P-2 environment. Click the Save button at the top or bottom of the form to save the feature in status and to remain in the record for additional data entry. The current status is displayed in both the status field and in the highlighted chevron at the top of the record. Clicking the Submit button saves the feature in status and returns you to the previously viewed page. Note that saving a Feature record in status does not generate tasks for the Feature. The following sections will detail the specific workflow and tasks associated with Feature Types. From Draft to Development When a feature is saved in status, a new button appears at the top and bottom of the form for initiating its development. The button is labeled Analysis & Design for Enhancement, Defect Correction, Monthly Reporting and Back-End Data Change types. Because infrastructure changes follow a different process for analysis and design and are documented in advance, the Page 22 of 22

23 Upgrade/Patch and Configuration types have a button labeled In Development as do applications that use JIRA for the process of analysis and design. It is possible to cancel a feature in change. status if there are no plans to move forward with the Analysis and Design Clicking the Analysis & Design button updates the status of the feature and automatically generates one required task for an Enhancement, Defect Correction and Back-End Data Changes. Develop and unit test code for FETR Options for generating additional tasks to document the design are available on the Documentation tab. The tasks associated with each option are created for the analysis and design phase only when a box is checked. Checking a box will also open additional options for that activity and generate optional workflow and tasks. For example, checking the Technical spec required? box, opens checkboxes for Technical spec needs approval? and a field to document the path to the specification. If checked, additional tasks for these options will be created. The Code peer review checkbox triggers mandatory fields for Technical peer contact and Functional peer contact. Figure 18: Documentation Tab on Feature form The following tasks are created automatically when the associated checkboxes are checked. Estimate functional effort Create requirements Review & approve requirements Create functional spec Review & approve functional spec Create technical spec Review technical spec Create test plan Review & approve test plan To notify other groups of the potential impact of the feature on related products or activities checkboxes and a dropdown are available on the Impact Implications tab for creating tasks for review. Examples of options follow: Checking the HDW Impact box creates a task for reviewing the potential impact that can be assigned to the HDW Practice; Checking the Application Security Impact box notifies the Client Services group that supports PeopleSoft that action is required for implementation of the feature; and Page 23 of 23

24 Setting the Financial Significant impact enables the user to classify the feature as having a material impact on the University's financial statement and thereby requiring an additional set of requirements for development, testing, approval and implementation. The default value comes from the Product record. Figure 19: Impact Implications Tab on Feature form Tasks for reviewing the HDW and Application Security impact are generated automatically; however, actions for financially significant features follow the procedures established by the Product group for the feature and represent a manual process. The areas listed in the Other impacts text box are informational only and trigger no tasks through the Release Management module. Note that buttons are also available under tabs on the feature record. The Update and Return button saves the data and returns you to the previously viewed page. The status of the feature, however, remains unchanged. It is necessary to click the Analysis & Design button to update the status and to create tasks associated with various options. Note that checkboxes cannot be updated and the associated tasks removed after the Feature record has been saved. If you create a task in error through a checkbox, open the task and enter 'Opened in error' in the work notes and set the status to before saving. See Chapter x, Working with Task Records, for more information. Development The status of features in becomes when the status of the task for developing and unit-testing the code changes from Pending. For Upgrade/Patch and Configuration type features, adding a configuration item (CI) under the Affected CIs tab triggers a task for confirming the infrastructure change in the development environment. Figure 20: Affected CIs Tab on Feature form Clicking the In Development button on the record updates its status from to and generates the appearance of two buttons, Ready for P-2 and Ready for P-1, but no deployment tasks for those environments. Page 24 of 24

25 For Application Development features, clicking the In Development button updates the status from to and generates tasks for developing features in JIRA and reconciling them with ServiceNow. The External Tickets tab provides a URL field for providing ticket information in JIRA. Clicking the Ready for P-2 button on a feature record of whatever type signals that development has completed and that the feature can move out of the development environment (P-3) and into test (P-2). ServiceNow will display an error message if all development tasks have not been completed. This action updates the feature's status to Ready for P-2 and creates a task to deploy the feature in the P-2 environment. From Development to Stage Deployment in P-2 Before deployment, make sure that the current release version for the feature has been designated on the record in the Release field. When the feature has been deployed and the task's status is saved as Completed, the status on the feature record changes automatically to. Tasks for testing the feature in the test environment appear in the Feature Tasks tab. The number of tasks listed increases by the number of new tasks created. Note that tasks for deploying features to P-2 vary according to the type of feature. The Upgrade/Patch and Configuration types requires identification of the CI for the installation to take place; whereas, the other types do not. Updating the status of the deployment task to Completed triggers the following actions automatically: Changes the status of the Feature record to ; Creates a task for testing the feature in the P-2 environment; and Displays a Ready for P-1 button. Approvals for P-1 Clicking the Ready for P-1 button lets the release manager know that QA testing in the P-2 environment for an individual feature has completed. Before it can move from QA/Test (P-2) to Test/Stage (P-1), the feature must have the approval of designated approvers. The release manager initiates the approval process by clicking the Awaiting for P-1 Approval button on the release record to generate approval records for the product, practice and release managers. (See the Chapter on Working with Release Records, Section XXXXX.) Note that all features for a release must have a status of for approval records to be generated. In addition, Features must be associated with a Release before moving to P-1. The release schedule informs the date for approvals to begin in the P-2 sign-off due date on the release record. Approving a feature automatically creates a task for deploying it in the P-1 environment, but does not update its status from. Figure 21: Feature record (Ready for P-1 status) Page 25 of 25

26 Completing the task to deploy the feature to P-1 updates the status of the feature to and generates tasks for validating the installation of testing the feature in the P-1 environment. A button, Ready for Production Approval, is also displayed on the Feature record. From Stage to Production The path from the stage environment (P-1) to Production is similar to the movement from Development (P-3) through QA/Test (P-2) to Test/Stage (P-1). Steps include Regression testing of individual features; Clicking the Ready for Production Approval button when the task for testing a feature has been completed; Requests for approval issued to practice and release managers; and Approval of individual features for deployment to Production. Approvals from the practice and release managers are required before a feature can be deployed to the production environment. The request for approval updates the status of the feature record to, and the approval itself changes the status to. Figure 22: Approval record (Feature) When all features have been approved, the release is ready to be deployed in the production environment in line with the schedule for the production release. The approval triggers a task in each feature for deploying it to Production. The status of both the release and the feature records is. Page 26 of 26

27 Figure 23: Feature record (Ready for Production status) From Production to Close The deployment of features, and therefore the release, to production has been scheduled in advance and in line with the dates on the release record. The Release Manager creates a schedule for deploying features and coordinates installation of the release, back-out plans, and subsequent validations with the deployment team as well as the product and practice managers. Completion of the task for deployment to production updates the status of the feature record to and generates tasks to validate that features work as expected in the production environment. Note that a Feature may be cancelled at any time before its status is. Closing the feature by clicking the Closed button updates the feature's status to. For Upgrade/Patch features it is necessary to update the CI for the feature before it can be closed. ServiceNow creates a task for this purpose if the CI needs updating checkbox is checked. Figure 24: CI needs updating checkbox (Task record) An overview of the Release and Deployment process for each feature type and associated tasks follows. Page 27 of 27

28 Enhancements / Defect Corrections Feature Figure 25: Enhancements/Defect Corrections workflow Page 28 of 28

29 Upgrade / Patch Feature Figure 26: Upgrades/Patches workflow Page 29 of 29

30 Configuration Feature Figure 27: Configuration workflow Page 30 of 30

31 Back-End Data Change Feature Figure 28: Back-End Data Change workflow Page 31 of 31

32 Monthly Reporting Figure 29: Monthly Reporting workflow Page 32 of 32

33 The following table provides a summary of feature status management through the phases of a release from planning to close. Release Phase Feature Status Status Update Trigger Planning P-3 Development Open new feature record Click button for Analysis & Design Status update from Pending on task to develop and unit-test code OR Click button for In Development Click button for Ready for P-2 P-2 QA/Test Status update to Completed on task to deploy feature to P-2 Click button for Ready for P-1 P-1 Test/Stage Status update to Completed on task to deploy feature to P-1 Production Post-production Table 4: Feature Status Management Click button for Ready for Production Approval Request for feature approval from release record Approval of all features for release to Production Status update to Completed on task to deploy feature to Production Click button for Close after all features validated and CIs updated where required Other Feature record information The Notes tab Use the Notes tab to create a Watch List for the Feature record. ServiceNow will automatically notify people on the list when there are updates to the Work notes on the Feature record. Click the lock icon to open the Watch List and enter the names and addresses for people you want to receive notifications. Note that use of the Notes tab does not affect workflow for the Feature. Page 33 of 33

34 Figure 30: Notes tab The External Tickets tab The External Tickets tab provides information on open issues and on tickets external to ServiceNow. The Open issues field displays a number that represents the number of open issues associated with the feature. The External Ticket link contains a URL field that allows you to enter links to JIRA tickets. (See above for features with the Application Deployment type.) Figure 31: External Tickets tab The Deployment Plan tab The Deployment Plan tab contains text boxes and URL fields for entering deployment instructions and a back-out plan. The information entered does not affect a feature's workflow, and it can be updated as deployment instructions and back-out plans take shape. Click the lock icons to open the URL fields for deployment instructions and back-out plans respectively. Figure 32: Deployment Plan tab Working with Issues (Bugs) Viewing Issue records For a list of all issues, click the Issues link on the Application Navigator to display a related list form. Page 34 of 34

35 Figure 33: Issues related list (from Application Navigator) The Issues tab on the Feature record displays a list of any issues associated with the feature itself. To view an Issue in detail click on the Number link of the record you want to view. All issue records have BUG as their identifier in ServiceNow. You can also view the Assignment group record, User record of the assignee and Product record by clicking the specified link on the list form. Figure 34: Issues related list (Feature record) Creating a new Issue/Bug Typically a Functional Contact will log an Issue with a feature as a result of testing. To open a new Issue record, click on the New button from the Issues related list on the Feature form or from the Issues related list in the Application Navigator. When you open a new issue from the feature record, ServiceNow automatically fills in the parent feature for the issue. Figure 35: Issue record The status becomes Pending when the issue is saved. The assignee is a technical contact. He is expected to resolve the issue and is responsible for updating the status as he makes progress on a fix as well as for adding work notes if needed. Options for status updates are as follows: Pending In Progress Ready for Testing Closed Cancelled Page 35 of 35

36 The Adding Dependent Features tab The Dependent Features tab displays a list of all dependencies associated with a feature. Clicking the Number link will open the feature record of the dependent feature. Figure 36: Dependent Features tab Page 36 of 36

37 6 Working with Task Records General Information A task is a unit of work that represents an action needed to implement a feature over the lifecycle of a release. Tasks are associated with each phase in a release and may differ from one phase to the next. Buttons and checkboxes on a feature record generate tasks based on the feature's type and the record's status. Additionally, an action on a feature, like an approval, can create a task. The Application Navigator provides three options for viewing tasks under the Release menu. 1. The Tasks option provides a list of all tasks by number, description, priority, status and product in the standard list form format. 2. The Tasks assigned to me option brings up a list form of all tasks by number, description, priority, status and product that have been assigned to you. 3. The Tasks assigned to my group option displays a list form with all the tasks by number, description, priority, status and product that have been assigned to your group in ServiceNow. Figure 37: Task list form (from Application Navigator) You can also open a list of tasks from the Feature Tasks tab on a feature record. Figure 38: Task list form (from Feature record) To view a particular task from any of the task list forms click its Number link to open the Task record. Page 37 of 37

38 Figure 39: New Release Task form Key fields on the task record are Number, Parent feature, Assignment group, Assigned to, Due date and Status. The Number, Parent feature, and Assignment group are automatically entered or defaulted from the Feature record. Use the Due date to inform the assignee when the task is expected to be completed. The dropdown on the release task record has options for updating the task's status. Options include the following: Pending Assigned In Progress On Hold Completed Cancelled All tasks have a status of Pending when first created. Assigned and In Progress indicate that the action needed is in the works, and Completed that all necessary work has been done. On Hold indicates that work has been suspended, and Cancelled that it will not be executed. If you create a task in error through a checkbox, open the task and enter 'Opened in error' in the work notes and set the status to Cancelled before saving. Make sure that a task is assigned correctly to both the group and the individual, as the Assigned to field may be blank. If a technical, functional or security contact changes on a feature, you need to update manually the Assigned to field on the task record with the new assignee. You can communicate progress on a task by using the Percent complete field on the task record. Whatever percentage is entered on the task will display in the Percent complete column as a progress bar in the task list form. Note that the percentage displayed results from a manual update of the Percent complete field on the task record. Add this column to the task list form by clicking the "gear" icon in the first column to bring up a form that enables you to personalize the list form's format. Page 38 of 38