Skip to end of metadata
Go to start of metadata

Post Mortems

Whenever any one of the mandatory (see "Mandatory stages vs Optional stages"pipeline stages fails the master branch of the AM Git repository will be locked automatically by jenkins and a slack message will be set out to the #am-entineering channel. If the auto locking fails for any reason follow the instructions in the Locking/Unlocking AM Git Manually section.

The master branch will remain locked until a post-mortem has been conducted to identify the root cause of the failure and actions have been created to resolve and improve processes, reliability, etc to avoid, reduce and/or mitigate the failure for occurring again.

The master branch will only be re-opened once the failed stage is know to be in a "passing" state.

Locking/Unlocking AM Git Manually

To lock:

To unlock:

DRIVE (Development Reliability ImproVEment) Team

DRIVE is a rotating responsibility that rotates around all AM development teams each sprint. Whilst a team has the DRIVE responsibility they have no other sprint commitments.

The DRIVE team is an "interrupt ready" team that are "on-call" to resolve any blocking issues that would prevent a product promotion (internal release) from taking place. Blocking issues include:

  • platform related blocking issues
  • product specific blocking issues
  • security issues, etc.

Many of the attributes of this team are derived from the Google SRE book, such as: max 50% of the teams time should be on interrupt driven issues, this is to allow for at least 50% of time to be committed to improving the root causes of those interrupts. If the 50% on interrupts is exceeded the members of the other AM development teams will join the DRIVE team until the balance is regained.

Security Issues that Impact AM Configuration

Certain Security Issues fixes will have an impact on the considerations that a customer must make at deployment in order to ensure that the deployment is adequately secured.  The most obvious example of this is fixes that add new security-related configuration fields (this is particularly important where the default configuration is that the security-related configuration is disabled); if you're unsure if this is the case for a specific ticket then please reach out to the security team for guidance.

This guidance is collated in the 'Security Guide' (AM 7) or the 'Deployment Planning Guide' - "Planning Security Hardening" / 'Installation Guide' - "Securing Installations" (AM 6.5.0 and lower) docs within the product documentation.

In order to ensure that this documentation change is captured the following process should be followed (DRAFT - to be finalised):

  • Raise an OPENAM Documentation task
    • Component/s: documenttion
    • Priority: Major
    • Security Level: security_issue
    • Provide a suitable description
      • Describe the security implication and the hardening requirement
      • Provide the steps required to enable/configure the security setting
  • Link documentation ticket as 'is required by' original security issue ticket 

  • No labels