Application Configuration Management and Change log

This is how to create and work an Application Configuration Change in Jira.  These changes need to be tracked as a valuable troubleshooting tool when problems arise in an application.  

Not all configuration changes will show up in the logs of each application.

Table of Contents

Creating Application Configuration Change ticket.

1. Go to the portal for the Application Configuration Management (ACM) project

   1. https://jira.cwf.org/servicedesk/customer/portal/5

   2. Log in using your CW AD/Email credentials

2. Select the appropriate change type for the change to the application you intend to make
   
   1. 
3. Fill out the form to create the issue in the JIRA project. Be sure to be as descriptive as possible.

Completing the Application Change.

1. Go to the project in Jira. https://jira.cwf.org/projects/ACM/queues/custom/91. Log in using your CW AD/Email credentials.
   
   1. 
2. By default all BOS related changes created from the portal will be assigned to the VC Support Staff user that is used already for Service Desk.
3. You can locate the change in one of the queues on the left of the page.  If going to the project takes you to any other screen than the one shown above you can click on the 'Queues' icon identified above.

Standard Change

Standard changes will be used for everyday tasks such as creating a new user or new workstation ID.  This will be used as change log to track these types of changes as they are not tracked very well by the application's log files.

1. Configure - Configure the change to the application.

2. Implement - Submit the change to the production environment and verify it was successful.  If not the issue can be transitioned back to configure.

3. Done - The change was successful.

Minor Change

Minor changes will be used for any changes that do not typically require IT involvement but will require testing. These changes may or may not require approval from accounting.

1. Configure - Configure the change to the application.  This should be done in the QA/Dev environment.
   1. 
   2. It is recommended that the process for making this change be documented so that the same process is followed when implementing to the Production environment.
2. Testing - Test the change in the QA environment.  There are three transitions from this status:
   
   1. 
   2. Testing Failed - If when testing your change you find adjustments are needed this will send the ticket back to Configure status
   3. Implement -  Select this if there is no need for approval from accounting. **Note, you will be required to comment why there isn't approval needed.**
   4. Submit to Accounting - This will send the ticket to Accounting Approval status.  At this point accounting will receive notification that approval is needed.  Please include any information that they will need for approval in the comments.  
      1. This will help prevent delays at this point.  
3. Implement - Implement the successful change to the production environment.
4. Production Testing - Test the change in the production environment.  
   
   1. 
   2. Testing Failed - If you find adjustments are needed this will send the ticket back to Implement status.
   3. Done - The testing was successful and the change is complete.

Major Change

Major Changes will be used for any change that will require IT involvement, for example Major Promotions and Discounts (Black Friday).  Also any change that will have a financial impact to customers.

Major Changes should be planned out at least a week to ten days in advance to insure ample time is given to complete the process and testing.

1. Planning- Verify all the appropriate information required for the change is noted in the ticket.
2. IT Verification - The IT lead for the application affected by the change is notified of the major change.
3. Configure - Configure the change in the QA/Dev environment.  
   
   1. It is highly recommended that the process for implementing the change is well documented so that the same process can be followed when implementing to the production environment.
4. Dev Testing - Test the change in the QA/Dev environment
5. QA Testing - The ticket at this point should be assigned to IT Quality Assurance. They will verify the testing and make sure no additional testing will be needed.
   
   1. If QA decides that no additional testing will be needed the ticket will be transitioned to Accounting Approval.
   2. If they decide that additional testing is required they will perform the testing.
6. Accounting Approval - As with Minor Changes accounting will receive notification that approval is needed.  **Note that you can't skip the accounting approval step.**
7. Implement - Implement the change to the production environment.
8. Production Testing - Test the Change in the production environment.

Approving a Change

Here are the steps to approving a change.  

1. When a change is submitted for approval the selected approvers will receive email notification from "JIRA Notifications".
   1. 
2. Navigate to the service desk customer portal by either selecting the link in your email, or entering the URL.
3. View the approval request and review the supporting information.
4. Select Approve or Decline, and add an optional comment if you want to (you don't need to add a comment, but if you're declining a request it's helpful to let the person who submitted the request know why you declined it). 
   1. The customer won't receive a response when you approve or decline a request, but they will if you add a comment.

Related articles