Skip to content

Instantly share code, notes, and snippets.

Last active Nov 26, 2017
What would you like to do?

Development workflow

All repositories follow Vincent Driessen's Gitflow model:

Cloned/forked repositories that Pull Requests base on should follow the model for compatibility and reasons.

Git sub-repository dependencies

The project is split into a main repository and its dependencies (sub-projects), located in repositories in the same organization.

Releases of the main project and its dependencies are usually independent.

Git branching model

  • master Always contains latest X.Y.Z stable release.
    • hotfix/* (e.g. hotfix/1.2.3) Quick releases for critical security issues. When ready, the hotfix branch is merged back to master, and develop (or release/*, if one exists).
  • develop Contains current development version with changes that were applied after the last release.
    • feature/* (e.g. feature/custom_avatars) New features being worked on. When completed and tested, the feature branch is merged back to develop.
    • release/* (e.g. release/3.2.1) Release preparation - version numbers and other metadata. Immediately preceding the actual release security patches are merged in and the release branch is merged back into feature and master.

The branching model also includes short-lived issue/* and task/* branches, which names either describe changes or contain a related issue number (e.g. issue-1337, task-coding_style_update), however they usually reside on users' repositories only. When multiple solutions to the same tasks or issues have to be hosted in a repository, the type/*/User pattern is followed in order to prevent branch name collisions (e.g. task/coding-style-update/Linus).

Repository milestones

Each repository maintains its own version history. Cross-repository milestones, if necessary, are denoted as Project:vVersion (e.g. Parser:v2.20) or Organization/Dependency:vVersion (e.g. Acme/Anvil:v3.2) for third party projects.

Default repository labels

All Pull Requests are linked to Issues, therefore there is no need to assign Types and additional classifications to them.

  • Type (Issues only)
    • t:bug - incorrect behavior,
    • t:enhancement- extending existing features,
    • t:optimization- optimizing existing features,
    • t:feature - introducing new features,
    • t:task - other tasks,
    • t:code-quality - code reformatting and restructuring,
  • Status
    • Issues
      • s:suggestion - issue under consideration,
      • s:confirmed - valid issue to be handled,
      • s:feedback - further discussion needed or problems found,
      • s:in-progress - issue currently being worked on,
      • s:resolved - tasks completed and ready to be implemented,
      • s:moved - issue moved to another repository,
      • s:deferred - issue that currently cannot be completed,
      • s:duplicate - issue that was registered before opening,
      • s:invalid - invalid report,
      • s:rejected - report rejected due to project's policy,
      • s:wontfix - issue valid but will not be resolved,
    • Pull Requests
      • s:feedback - further discussion needed or problems found,
      • s:in-progress - work in proposed branch is in progress,
  • Priority
    • p:low - minor priority,
    • p:normal - standard priority,
    • p:high - high priority,
    • p:critical - blockers that need to be resolved before next release,
  • Additional tags (Issues only)
    • 3rd-party - issues regarding third party projects.
    • easy-pick - issues that be resolved without deep project involvement or of small scope.

Additional labels in maintenance repositories

  • Type
    • t:maintenance - non-security operations,
    • t:security - tasks related to security issues,
  • Severity - based on the CVSS scale
    • sev:none
    • sev:low
    • sev:medium
    • sev:high
    • sev:critical

Additional labels are listed in files.

Release cycle

  1. Development

    • Standard release:

      • GitHub-based development in public repositories (develop and child branches).

      • Security-related development in maintenance repositories (develop and child branches).

  2. Pre-release

    1. Branch setup

      • Hotfix release:
        1. A hotfix/* branch is created off master in one or both of public and maintenance repositories.
        2. A Pull Request from hotfix/* to master is created in one or both of public and maintenance repositories for release-related discussion.
      • Standard release:
        1. A release/* branch is created off develop in the project repository, containing updated version numbers and metadata. Commits to develop after that point will not be included in that release.
          • Bugs found in release/* are patched in that branch, which is being merged back to develop.
        2. A Pull Request from release/* to develop is created with the s:in-progress label to discuss related issues in both repositories.
        3. A release/* branch is created off develop in the maintenance repository and the previously created branch is merged in.
          • Bugs found in release/* are patched in that branch, which is being merged back to develop.
          • The equivalent public branch is merged into the maintenance one whenever changes are committed.
    2. Builds and packages
      1. Quality Assurance packages are generated basing on the working branch in the maintenance repository:
        • The packages are regenerated for each series of commits to the branch,
        • Last package commits are tagged with the RC* suffix (e.g. 1.2.3-RC2).
        • The packages are digitally signed with by at least two members of any of the Development, Security, and Management teams whose public keys are publicly available. The package filenames, including the intended version and package numbers, must be included in the signatures. The signatures are distributed with each QA package.
        • The last QA package becomes final after 3 days have passed since it was published for testing.
    3. Documentation
      • The release notes blog post draft is created.
      • Documentation sections are being prepared to be published or modified.
  3. Release

    1. Git

      • Hotfix release:
        1. The hotfix/* branch is merged from the maintenance repository to its equivalent in the public repository.
        2. The hotfix/* branches are merged back to master, and develop (or release/* if there is one present).
        3. The top commits in master branches are tagged with intended version number.
      • Standard release:
        1. The release/* branch is merged from the maintenance repository to its equivalent in the public repository.
        2. The release/* branches are merged back to develop and into master.
        3. The top commits in master branches are tagged with intended version number.
    2. Package publishing

      1. Signing

      The final package is digitally signed by at least one member of the Management team and two members of any of the Development and Security teams, all of which must be located in at least 3 distinct countries. The package filename, including the intended version, must be included in the signatures. The signatures are verified by at least two members of both Management, Development, Security, and non-engineering teams. The signatures are distributed with the package.

      1. Documentation
        1. The release notes are complemented with the package and related signatures.
        2. The documentation is complemented with information that could not be published before the release.
  4. Post-release

    1. Security Hall of Fame is complemented with reports of fixed security issues.
    2. Final feedback is generated for reporters of fixed security issues.

Security workflow

If the report is rejected at any point, the workflow skips to Final Feedback.

  1. Reporting

    • Team members handling security issues and team leaders are required to have available and accessible public keys.
    • No initial reports should be transmitted over unencrypted or insecure channels.
  2. Report handling

    1. Confidentiality assurance

    If the report is located in a publicly accessible location, a team member attempts to soft delete it (if possible, e.g. Community forums) or contact the author (or other party that might help removing it temporarily).

    1. Alerting team members

    A team member alerts the team (preferably on internal Slack #security channel) and provides links and/or information.

    1. Initial feedback

    If applicable, a team member response to the author that their report has been acknowledged and is being processed.

  3. Internal processing

    1. Issue in corresponding private repository created

    All public repositories have their private, maintenance counterpart suffixed by -prep. A team member opens an issue providing detailed description and assigns first labels.

    1. CVSS scale assessment

    The vulnerability is being assessed by team members handling security issues: CVSS base metrics are being provided in the opened issue and a summary sev: label is being added.

    1. Countermeasures implementation
      1. The development team and security team members prepare and implement measures (including code patches, advisories and third party cooperation) that will eliminate or mitigate affected environments and prevent related threats in the future.
      2. Prepared countermeasures are being verified internally.
  4. Releasing

    1. QA packages verification

Team members handling security issues verify that the release candidate QA packages contain valid countermeasures.

2. ##### Release
The maintenance repositories containing countermeasures are being merged into their public counterparts. The final QA packages are being marked as final and are being released.

3. ##### Documentation
The security issue details are being provided in release notes.

4. ##### (Main repository merge & release)    
If the vulnerability was fixed in a subrepository, the issue details are being attached to the release notes once the main package is released.

5. ##### Reporter recognition
If applicable and unless the reporter has asked to do otherwise, a team member handling security issues adds the original reporter's and issue details to project's _Security Hall of Fame_.
  1. Final feedback

    If applicable, a team member responds to the original reporter providing status and details of the issue and information on Reporter recognition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment