Appendix

Owned by Łukasz Krupa (Unlicensed)
Nov 13, 2018


Challenge

Changes made in one JIRA are isolated, they are not propagated automatically to remote JIRA instance. This delay may cause many problems and unexpected behavior and attract lot of attention and efforts to revert changes.

This section gives better understanding and described how to handle such situations.


What can change?

  1. Connection settings - for example infrastructure changes, or password changes - what will be the symptoms in this situation? All messages will get error status, they can be retry when problem will be solved.

  2. Contract changes - has major influence on remote JIRA instance

  3. JIRA technical user change permission, roles or is no longer presence.

  4. JIRA project settings can change - required fields and others

  5. Workflow can be changed - has influence on status synchronization

  6. More than one customfield of type Issue  Status Synchronization, or Synchronized issues will be added.


What influence can those changes have on JIRA in time aspect?

Basically if we edit local contract remote JIRA still send different data so the result is invalid, even parallel change do not guarantee that data will be consistent. Possible solutions:

  • Block contract edition (by policy)

  • Make contract changes in maintain window, to be sure that no one will create issue


How to deal with changes?

  1. When connection settings change - errors appear and all messages/communication have to be repeat on both instances 

    1. If connection will be deleted all contracts related to connection will be deleted too.

  2. If contract changes:

    1. If required field is no longer in mapping - an error appears, json in queue has to be changed and message has to be retry

    2. If new field appear in contract - then is not mapped, so data are lost

    3. If project or issue type change - all new issues will be synchronized in new issue type/project , all updates still will be made in last issutype/project. Updates are insensitive on issutype/project, they works on issue key/ issue id

    4. If contract will be disabled/removed then updates/create messages will not be collected/ remote updates will cause errors, message processing can be repeated

  3. If technical user change:

    1. If user don't have permission to add/comment/attachments/update an error appears - all messages can be repeated in order to keep data synchronized

    2. If user don't have permission to browse other changes will be collected and synchronized

  4. If project change:

    1. New required fields will be added, which is not in field mapping - errors appears and all messages have to be repeated

    2. If field will be no longer in the screen changes will not be collected

  5. If more than one customfield will be added - there will be some unexpected behaviors.