Skip to main content

 

Planview Customer Success Center

Planview System Change Control Procedure - LeanKit

 

 

 

Planview System Change Control Procedure - LeanKit
   

PLANVIEW SYSTEM CHANGE CONTROL PROCEDURE - LEANKIT

APPROVALS

All approvals are maintained and controlled on the https://success.planview.com page.

REVISION HISTORY

Author Revised Section/Paragraph Rev Released
LW Initial draft 1.0 2019-01-31

Draft versions are not to be used. Distribute only the published version of this document.

PURPOSE

Planview LeanKit team members use LeanKit and GitHub to define the work that embodies a release and to securely manage source control.

SCOPE

Planview LeanKit solution. 

DEFINITIONS

  • Fireteams Fireteams consist of 2-4 developers. New developers are paired with more experienced developers within their fireteam.
  • Pull RequestPull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.1
  • GitHub Terms  The following terms are specific to GitHub.2
    • Private Repository 
    • Upstream Feature Branch 
    • Master Branch

ROLES AND RESPONSIBILITIES

  • Development Team – Works with the Test Team to manage software definition, software development, software test, software operation, and software end-of-life.
  • Test Team –  Works closely with the Development Team, participating in software development, software test, and software operation.

PROCEDURES

Development and Bug Fixes

  1. Application features and enhancements are defined by Product Managers.
  2. The specifics of the feature/enhancement are documented as Cards in the LeanKit environment. LeanKit developers use the LeanKit application as a fundamental component of the process for all phases of development and change control. 
  3. LeanKit developers create the feature/enhancement according to the definition provided by Product Managers, keeping the following in mind:
    • Application security - designing the code to prevent cross-site scripting, injections, man-in-the-middle attacks, and so on.
    • Leveraging already-defined code where possible.
    • Modularizing code where possible.
    • Designing for clear testing abilities.
    • Designing for high performance.
  4. Developer provides unit tests, which includes automated static analysis.
  5. Developer submits a pull request (PR) to get the updated code merged into the feature branch. This process is conducted using pair programming to ensure qualified review of the code.
  6. Once the PR is submitted, several automated processes take place to publish the change:
    1. New code is deployed to a development environment by a continuous deployment bot that monitors a Kanban board in LeanKit for code in need of deploy.
    2. An upstream feature branch of the code is deployed.
    3. Quality engineering teams test the changes both by running automated UI and API tests, and they also manually test the steps. If any issues are found, developers rework the code and go through the process again.
    4. When quality engineering tests are passed, a PR is opened from the upstream branch to the main branch. 
    5. Automation engineers merge the PR and create a semantic version tag.
    6. The newly merged-into-master-and-tagged code will be deployed into the integration environment, where automated UI and API tests are run. Once these automated tests pass, the code is then deployed to production instances.

Patching

Patching of all physical hardware is maintained by Microsoft Azure. Software, operating system, application, and all host-based services are patched by LeanKit network operations. Patching on LeanKit systems is automated to ensure that the most recent working patches are in place. Prospective patches are presented to the change advisory board for approval prior to being applied.

RELATED DOCUMENTATION

  • Planview LeanKit Secure Software Development Lifecycle Policy
  • ISMS-F1 Planview Change Management Policy

REVIEW AND SIGNOFF

 
Reviewed by ______________________________________________________________  
Name ___________________________________________________________________  
Position __________________________________________________________________  
Date_____________________________________________________________________  

 


1 Source: https://help.github.com/articles/about-pull-requests/

2 Source: https://guides.github.com/introduction/flow/