Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-9523

Group a set of PRs together as a logical unit


    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • None
    • None
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      With a "microsevices" approach to systems architecture becoming ever more popular, it would be nice to be able to mark a set of PRs across different repositories (and even different projects) as being a component of a conceptual whole which should either be accepted (and merged) or rejected in toto.

      This functionality could also be conceptually tied to the JIRA ticket links as well (optionally) so that tickets may be marked as requiring the work to be merged in the same set of PRs and that marking would then add the tickets to a "PR Set".

      There's lots to be said for keeping each change required in a system local to a single repository and ensuring that the change doesn't break the world... but in practice we find that working with large complicated microservices systems inevitably leads to changes required across multiple repositories "all at once" in order to ensure a consistent and functional baseline to test against.  

      A "PR Set" feature would also help systems integrators to better understand when software developers have completed all of the necessary tickets/stories in order for a feature to be "testable".  Developers could list all PRs in a Set, check them out locally, and test against the proposed changes (or even wire the PR Set into Jenkins to do automated functional testing across live services running in a development cluster).  

      I know JIRA already allows users to link many tickets to 1 PR or 1 PR to many tickets, but what would be nice is to be able to somehow have the ability to review all PRs related to a given ticket as one conceptual unit and then choose to either merge or reject the whole bunch.  I believe this would go a long way toward keeping feature changes grouped together when your code base is spread across potentially many hundreds of small repositories. 

            Unassigned Unassigned
            b2a16e6770c4 Andy P
            0 Vote for this issue
            2 Start watching this issue