Integrations
      Back to home
      1. Help Center
      2. Integrations

      Merging code into a production branch

      Purpose
      This section outlines Kongo's process for merging code into the production branch to ensure that all changes are reviewed, tested, and approved prior to deployment. The goal is to maintain system stability, security, and alignment with business requirements while leveraging Bitbucket as the version control platform.
      Scope
      This policy applies to all developers, system administrators, and stakeholders involved in deploying code changes to the production environment managed in Bitbucket repositories.
      Process for Merging Code into the Production Branch
      1. Branching Strategy
        • All development work occurs in feature, bugfix, or hotfix branches created from the develop branch (e.g., feature/feature-name, bugfix/issue-id, hotfix/description).
        • The main branch (or equivalent, e.g., production) serves as the production-ready branch and is protected from direct commits.
        • Branch naming conventions must follow the format: [type]/[short-description].
      2. Code Development and Commit
        • Developers commit changes to their respective feature/bugfix branches with clear, descriptive commit messages.
        • Commits should reference relevant issue or ticket numbers (e.g., "Fixes #123 - Resolve login timeout issue").
        • Unit tests and documentation updates must accompany code changes where applicable.
      3. Pull Request Creation
        • Once development is complete, the developer creates a pull request (PR) in Bitbucket to merge the feature/bugfix branch into the develop branch.
        • The PR must include:
          • A concise title summarizing the change (e.g., "Add user authentication endpoint").
          • A description detailing the purpose, scope, and any dependencies or risks.
          • Links to related tickets or documentation.
        • The developer assigns at least two reviewers (e.g., a peer developer and a team lead) based on project team roles.
      4. Review and Approval
        • Reviewers assess the PR for code quality, functionality, adherence to coding standards, and test coverage.
        • Bitbucket’s pull request review tools (e.g., inline comments, tasks) are used to provide feedback.
        • A minimum of two approvals is required before merging into develop. Approvals are tracked within Bitbucket.
        • If changes are requested, the developer updates the branch, resolves comments, and resubmits for review.
      5. Automated Testing and Builds
        • Upon PR creation, Bitbucket pipelines (or integrated CI/CD tools) automatically trigger unit tests, integration tests, and static code analysis.
        • The PR cannot be merged into develop unless all automated checks pass successfully.
        • Failed builds or tests must be resolved by the developer before re-submission.
      6. Merging into Develop
        • After approvals and successful builds, the PR is merged into the develop branch using Bitbucket’s “Merge” button with the “Squash” or “Merge Commit” strategy (as defined by the project team).
        • The feature/bugfix branch is deleted post-merge to maintain repository cleanliness (configurable in Bitbucket settings).
      7. Staging and Validation
        • Changes in develop are deployed to a staging environment for additional testing (e.g., user acceptance testing, performance testing).
        • Any issues identified in staging must be resolved via new bugfix branches and PRs back into develop.
      8. Production Merge Request
        • Once validated in staging, a release manager or designated team member creates a pull request to merge develop into the main (production) branch.
        • The PR requires:
          • Approval from a senior developer or technical lead.
          • Confirmation of successful staging tests (e.g., via attached test reports or checklist).
          • A deployment window scheduled with the operations team to minimize disruption.
        • Bitbucket branch permissions enforce that only authorized personnel (e.g., release managers) can approve and merge into main.
      9. Production Deployment
        • Upon PR approval, the merge into main triggers the production deployment pipeline (via Bitbucket Pipelines or an integrated tool).
        • A deployment tag (e.g., release-v1.2.3) is created on the main branch for versioning and rollback purposes.
        • Post-deployment smoke tests are conducted to verify production stability.
      10. Documentation and Monitoring
        • The release is documented in the project’s changelog or release notes, including a summary of changes and deployment date.
        • Monitoring tools (e.g., logs, alerts) are observed post-deployment to detect anomalies, with rollback procedures initiated if necessary.
      Roles and Responsibilities
      • Developers: Write, test, and submit code changes via pull requests.
      • Reviewers: Evaluate and approve pull requests for quality and compliance.
      • Release Manager: Oversees merges into main and coordinates deployment.
      • Operations Team: Monitors production stability and supports deployment windows.
      Tools
      • Bitbucket: Repository hosting, pull requests, branch permissions, and pipelines.
      • CI/CD Integration: Automated testing and deployment (e.g., Bitbucket Pipelines, Jenkins).
      • Communication: Team channels (e.g., Slack, email) for PR notifications and deployment updates.
      Exceptions
      • Hotfixes: For urgent production issues, a hotfix branch is created directly from main, follows the same PR process, and is merged back into both main and develop.
      • Any deviation from this process requires approval from the technical lead and must be documented.
      Audit and Compliance
      • All merges into main are logged in Bitbucket’s audit trail, including approvers and timestamps.
      • Periodic reviews of the change control process are conducted to ensure adherence and identify improvements.