Skip to content

Latest commit

 

History

History
63 lines (45 loc) · 5.06 KB

Development-Process.md

File metadata and controls

63 lines (45 loc) · 5.06 KB

Development Process

At Babylon security is something we have always in mind when developing software and that is why we follow the SSDLC (Secure Software Development Life Cycle) framework. Alongside this framework, we also use a few services to help us keep track of what we are building and make sure we deliver a secure and stable product.

There are 3 services we use daily:

  • Jira: is where the development process begins. Once a ticket has all the necessary details, dev can pick it up and implement it
  • GitHub: used for hosting our project and version control using Git
  • CircleCI: our continuous integration service to run tests when integrating PRs

1. Get a Jira ticket 🎫

  • Every development task that results in a PR must have a Jira ticket
  • The ticket must be assigned to the engineer who is going to work on it. The engineer should make sure it has all details and designs attached (if applicable).
  • The ticket will be moved to In progress once development is ready to start (this might be automatically done by the bot when the branch is published, if configured)

2. Get started with development 🛠

  • Create a branch where this work will live. Please follow this format: <author's_name>/<ticket-id>-<small-description (optional)> (E.g. john/TCKT-123-fix-bug)
  • For new features, add a local feature switch to avoid getting WIP code into the release. Add the name of this flag (and additional instructions) to the ticket to help QA test it
  • Implement all features, changes to satisfy the acceptance criteria defined in the ticket. You can find more info about this in the Architecture section
  • If it introduces a new component, add it to the GalleryApp and make sure it's included in the Design System

3. Testing 🧪

  • Our features should include the following type of tests:
    • Snapshot tests should be added to new components and screens
    • Logic, ViewModels, SDK changes should be unit tested
    • Automation tests should be updated or added
  • Please test the GalleryApp and Babylon apps by building and running them before merging to avoid checks failing

4. Creating the PR 📝

  • Fill in the PR template and set the title using the following format: [TCKT-123] Short summary of work
  • Add labels if necessary
    • To open a work in progress PR, use GitHub's draft PR feature and pusblish it once it's ready for review. Reviewers will only be requested for published PRs.
  • Thanks to a GitHub action, the PR will automatically be assigned to its creator
  • Move the ticket to Peer review on Jira (or it'll be automatically moved if configured)
  • If you'd like feedback before the work on the ticket is done, open a draft PR so your peers can leave comments
  • To run checks before merging, use the comment @ios-bot-babylon test_pr (more info)

5. Merging PR 🚦

  • Once a PR has 2 approvals and no outstanding comments/changes requested, the Merge label can be added to begin the merging process
  • Our bot will add it to the merge queue and integrate it into the rest of the project
  • Once it reaches the front of the queue, it's updated with the target branch and CircleCI runs all necessary tests to make sure nothing's failing. Note: there's no need to trigger checks manually, if there are other PRs in the queue.
  • If the required checks are passing, the PR is merged and the branch deleted.
  • The ticket is moved to Awaiting build on Jira by our bot. It will be updated to Ready for QA when the next App Center build is created. (if configured, otherwise this should be done manually)
  • If the checks fail, you will have to analyse what is the reason for the failure, fix it, and add the Merge label again

6. QA 🧑‍💻

  • Once the work is in the App Center builds, QA can test it to make sure everything works correctly
  • It's important that the engineer assigned to the ticket doesn't QA their own work
  • When QA is done with testing, the ticket can be moved to Done on Jira

7. Release 🚢

  • When releasing a feature that was under a local feature flag, make sure it is removed before the release branch is cut
  • During the release process, the ticket is updated with the release version
  • Once the app is published, the ticket is done and our users can use it 🚀