Overview

Utilizing a staging environment with development, test, stage (optional), and production servers is a standard practice in software development that ensures code quality, stability, and reliability before it reaches the end-users. The same practice applies to Application Lifecycle Management (ALM) and the Codebeamer deployment feature allows transferring and updating project hierarchies between Codebeamer instances.

Since Arthrex will not be using the "Deployment" feature Arthrex will need to rely on a more manual method to promote changes in the Dev environment over to their Production environment. This will necessitate the creation of a Change Management System/Methodology.

This document describes IQNOX's recommendation and application of this best practice.

Why should Arthrex use Best Practices?

For a successful Change Management System, a well-defined business process is required. It helps in many ways: -

• Structured Approach: Best Practices provide a structured approach to change management, ensuring changes are systematically planned, evaluated, and implemented.

• Consistency: Standardized Best Practices ensure that changes are handled consistently across the organization, reducing the likelihood of errors and oversights.

• Efficiency: Well-documented processes streamline the change management workflow, minimizing delays and resource waste.

• Communication: Best Practices define clear roles, responsibilities, and communication channels, ensuring all stakeholders are informed and involved in the change process.

• Risk Management: It helps organizations identify, assess, and mitigate risks associated with changes.

• Documentation & Traceability: Best Practices enforce thorough documentation of all changes, providing a traceable record for future reference, audits, and compliance.

• Continuous Improvement: Best Practices include feedback loops and post-implementation reviews, allowing the organization to learn from each change and continually improve its change management practices.

Codebeamer Deployment Feature

A Codebeamer project is comprised of Project Configuration Deployment or Horizontal Deployment allows for transferring and updating complex project hierarchies between Codebeamer instances.

Codebeamer deployments can be a mixture of pure in-app configurations and external code that is deployed to the web application server, although not all deployments utilize external code. A deployment is generally

1. Code Development:

   • Developers write and commit code in the development environment.

   • Code is tested locally and undergoes peer reviews.

2. Initial Testing:

   • Code is pushed to a version control system and integrated into the test environment.

   • Automated tests run to catch regressions and verify functionality.

3. Staging Deployment:

   • After passing initial tests, the code is deployed to the staging environment.

   • More extensive testing occurs, including performance and security tests.

   • Final user acceptance testing (UAT) is conducted to validate changes against requirements.

4. Approval and Release:

   • If the staging environment tests are successful and stakeholders approve, the code is scheduled for production deployment.

   • A release plan is prepared, detailing the deployment steps, rollback procedures, and communication plan.

5. Production Deployment:

   • Code is deployed to the production environment.

   • Monitoring tools track the deployment to quickly identify and resolve any issues.

   • Post-deployment tests ensure the system is operating as expected.

Principles of Managing Change

Arthrex must need to follow certain rules/principles while managing change between different environments: -

• Each environment must be independent of other environments.

• Each environment must be identified by a name and a current version.

  • For example: DEV is at 1.2.0 and PROD is at 1.0.0

• Changes must “start” in only 1 place – DEV

  • No one makes changes to “downstream” environments directly, except during change deployment.

• Changes must be manually propagated between environments during change windows.

Manual Deployment Process

Manual Deployment process consists of the following steps: -

1. Maintain a Record of Changes

   • Purpose-

     • Because Codebeamer cannot identify changes to configuration systematically, we must do so manually.

     • Document individual features, enhancements, bug fixes, or changes.

     • Create an “atomic” reference defining the change outside of the system.

     • Provide context for testing and validation.

   • RACI-

     • Responsible: Software Developers

     • Consulted: Codebeamer Administrator

     • Informed: Business Analyst

   • Dependencies-

     • A place to document the change in detail.

     • A place to summarize the state of the change among other changes.

     • A standard way of describing the changes.

       • State model for changes

   • Inputs-

     • Code and configuration changes required for each change in scope.

     • Specific entities which are added, changed, or removed.

   • Outputs-

     • An entry in the summarized list of changes.

     • Changes made to development environment.

2. Scope the Release

   • Purpose-

     • Select individual changes to assemble into a release, considering the scope, dependencies, time, and risk associated with each change.

   • RACI-

     • Responsible: Business Analyst

     • Consulted: Project Manager, Stakeholders, Development Team

     • Informed: Codebeamer Administrator, Risk Management Specialist,

   • Dependencies-

     • Change descriptions, including details of changes made to Codebeamer for each change.

     • Business Requirements: Clear and detailed requirements from business stakeholders.

     • Access to Systems: Access to the relevant projects and trackers on the source and target systems.

     • Stakeholder Input: Input and validation from stakeholders.

     • Any user feedback driving the changes.

   • Inputs-

     • Change records, System backlogs, Risk tolerance, Calendar/schedule, Staff availability

     • Version log

   • Outputs-

     • Release definition

   Semantic Versioning

   Semantic Versioning is a versioning standard for communicating changes in software or a system. It follows the format 'MAJOR.MINOR.PATCH'.

   • Major represents large changes to the system that add brand new trackers (newly introduced business processes) or large changes that completely redesign how an already existing business process or tracker works.

   • Minor represents small bits of newly added functionality such as new fields, new state transitions, permissions, etc. that are added to already existing trackers, projects, reports, etc.

   • Patch represents bug fixes, simple renaming, small quality-of-life improvements, etc.

   • Example (Major Change)

     • Problem Statement: Project Administrator wants to update the system version from 1.0.0 to 2.0.0. This would be prompted by adding a brand new tracker, called Risk Report to the existing system, v. 1.0.0. (considered a major update).

       
       

   • Example (Minor Change)

     • Problem Statement: Project Administrator wants to update the system version from 2.0.0 to 2.1.0. This would be prompted by adding a new field, called Risk Summary to the existing Risk Report tracker (considered a minor update).

       
       

   • Example (Patch Change)

     • Problem Statement: Project Administrator wants to update the system version from 2.1.0 to 2.1.1. This would be prompted by renaming the Risk Summary field to Risk Overview (considered a patch).

       
       

3. Plan the Release

   • Purpose-

     • Create a detailed action plan for implementing the changes, including timelines, resource allocation, and contingency plans.

     • Create test plans to ensure change requirements are met.

   • RACI-

     • Responsible: Project Manager

     • Consulted: Codebeamer Administrators, Business Analyst, Development Team

     • Informed: Stakeholders

   • Dependencies-

     • Resource Availability: Availability of personnel, tools, and time.

     • Communication Plan: Established communication channels.

   • Inputs-

     • Release Description

     • Change Definitions

   • Outputs-

     • Change implementation plan, Resource allocation plan, Communication plan, Contingency/Rollback Plan, Test Cases and Scenarios

   • Risks-

     • Change conflict resulting in an incomplete understanding of the scope or dependencies of the change.

4. Test

   • Purpose-

     • Validate the planned changes in test projects with test data in the source environment to ensure they work as expected without any negative impact.

   • RACI-

     • Responsible: Quality Assurance (QA) Team

     • Consulted: Codebeamer Administrators, Test Engineers, Developers

     • Informed: Stakeholders

   • Dependencies-

     • Separate projects for testing in the Dev environment

     • Ability to populate test projects with test data

     • Test Cases and Scenarios

     • Test Data

     • Collaboration with the QA team.

   • Inputs-

     • Change implementation plan, Test cases, Test environment setup, Test data

   • Outputs-

     • Test results, Test project feedback, Adjustments to the plan if needed, Defects or Issues

     • Changes to deployment plans

   • Risks-

     • Change overlap in source environment with unscheduled changes may result in a gap that can’t be identified until changes are made in the target environment.

5. Execute the Migration

   • Purpose-

     • Carry out the planned changes in the target environment according to the established plan.

   • RACI-

     • Responsible: Development Team

     • Consulted: Project Manager, Codebeamer Administrator

     • Informed: Stakeholders, Business Analyst

   • Dependencies-

     • Formal approval to proceed.

     • A detailed step-by-step plan for implementation.

     • Access and proper permissions for relevant projects and trackers in the target system

     • Availability of backup and recovery solutions.

   • Inputs-

     • Finalized change implementation plan, Formal approval, System, project, and tracker access, recovery and backup system

   • Outputs-

     • Executed changes in the production system, Change logs, Incident reports (if any)

6. Verify Changes

   • Purpose-

     • Ensure that the changes have been implemented correctly and that the system is functioning as expected.

   • RACI-

     • Responsible: Codebeamer Administrators

     • Consulted: Developers, Project Manager

     • Informed: Stakeholders

   • Dependencies-

     • Access to system monitoring tools.

     • Feedback from end-users.

     • A checklist of criteria to confirm correct implementation.

   • Inputs-

     • Executed changes, System monitoring tools, User feedback, Implementation criteria checklist

   • Outputs-

     • Verification reports, User Acceptance, System performance metrics

Verification Required for Successful Deployment

Once the deployment is done, Arthrex needs to verify the changes because it ensures that the changes applied are accurate, effective, and do not introduce new issues. This process involves checking that the changes meet the specified requirements and function as intended in the live environment.

Error Detection

It identifies and corrects mistakes before they impact the production environment.

Quality Assurance

It confirms that the changes achieve the desired outcomes without adversely affecting other system components.

Risk Mitigation

It reduces the likelihood of unexpected problems, minimizing downtime and disruptions.

Compliance

It ensures adherence to regulatory and internal standards.

User Confidence

It builds trust with users by ensuring the stability and reliability of the system after changes are implemented.