Skip to content

Vendor updates

All DPL projects make use of libraries and other tools managed by third parties (vendors). This describes our general process for handling updates to these:

  1. Vendored code must be kept up to date.
  2. Updating vendored is a continual process which is carried out as a part of the normal release cycle.
  3. We trust our automated tools to identify updates and locate problems with updates to vendored code.
  4. We rely on our knowledge about the projects and vendors to identify updates which require further scrutiny.

Projects have a more specific process for managing vendor updates can provide further information as part of the project-specific documentation.

Dependabot

We use Dependabot to monitor vendor code and create pull requests in case there are updates.

Handling pull requests

When handling a pull request created by Dependabot the developer handling the pull requests does the following:

  1. Consider the risk of the update. High risk updates are less likely to be merged directly. We consider the following factors when determining risk:
  2. Update level: Major releases are more risky than minor and patch releases as they contain breaking or other significant changes.
  3. Impact: Updates to core frameworks of the project are more risky than updates to code supporting single features.
  4. Usage: Updates to dependencies used during development are considered less risky than updates used in production.
  5. Test coverage: Updates to dependencies used in areas which are covered by tests are considered less risky.
  6. Check the status of the GitHub Actions workflows for the pull request. If one of these fail then we never apply the update directly.
  7. If the person decides that the update is safe to merge they merge the pull request directly.
  8. If the person decides that the update should not be applied directly they:
  9. Update the Dependabot configuration to ignore the dependency version in question. If a new major version is failing we may still want to include minor and patch releases.
  10. Create an issue in JIRA with the following information:
    • Type: Task
    • Title: Opgrader [vendor project name] ([DDF project name])
    • Description:
      • A short description of the library, the role it plays within the project, why you do not think the update requires additional scrutiny and a link til the pull request created by Dependabot. All is Danish. This provides context to the business and the person handling the update in the future.
      • Reference to the added ignore configuration (4.1) which must be deleted after the update.
    • Project: DDFNEXT
    • Sprint: Opdateringer
  11. Close the Dependabot pull request.

Configuration

We configure Dependabot with the following properties:

  • Schedule: Vendors should be checked weekly at night between sunday and monday. This ensures updates occur frequently and on a regular basis across all projetcs.
  • Limit: By default we set a high limit for number of pull requests. e.g.
  • We prefer many smaller updates arriving as quickly as possible. Dependabot will use a limit of 5 if no limit is provided. For some projects creating many pull requests risk affecting other resources. This may warrant a lower limit on pull requests and/or additional grouping.
  • Groups
  • In general keep groups to a minimum. This avoids creating pull requests which cannot be merged directly due to a single vendor causing status checks to fail.
  • Use groups to ensure that dependencies that are usually updated in conjunction (and usually by the same vendor) are handled appropriately without creating multiple pull requests. Examples:
    • react, react-dom and their related @types packages
    • drupal/core, drupal/core-recommended and drupal/core-composer-scaffold
  • Versioning strategy: The minimum version should always be set to the latest version. This prevents accidental downgrades.

Updating a Dependency

If we update a dependency manually we do the following:

  1. Create a ticket in JIRA. If a ticket for the update has already been created through our Dependabot workflow we move it to the current project. If not then we create a new one with similar information as when it is created from a Dependabot update
  2. Update the dependency using our standard development process. The pull request must not contain unrelated changes to ensure the integrity of the project.
  3. If the change is not considered risky then we merge the pull request after internal review without further testing.