Onboarding

New CA developer onboarding guide

Software you'll need installed

Name	Frontend	Backend
Git	✅	✅
IDE (VS Code)	✅	✅
Docker	✅	✅
Node + NPM	✅	✅
Typescript	✅	✅
Xcode	✅	❌
Android Studio	✅	❌
Teleport	❌	✅
React Native	✅	❌

Systems you'll need access to

Name	Frontend	Backend
Slack	✅	✅
Google	✅	✅
1Password	✅	✅
Asana	✅	✅
GitHub	✅	✅
AWS	✅	✅
Framer	✅	❌
Teleport	❌	✅
Bitrise*	✅	❌
Apple Developer	✅	❌
Google Developer	✅	❌
GitBook	✅	✅
Least	✅	✅
Uplevyl	✅	✅
Limelight	✅	✅

GitHub

Please send us your GitHub username (it can be your public Github account or you can make one specifically for CA work).

You'll be invited to the Chelsea Apps organisation, which will give you access to all the CA repositories (older repositories may still be on Bitbucket but are archived).

You'll need to have two-factor authentication enabled before you can join the organisation

GitHub Packages

We use GH packages to host custom NPM packages. To authenticate, set up a Personal Access Token on GitHub and follow the instructions here:

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#authenticating-with-a-personal-access-token

AWS

We use AWS SSO to allow developers access to AWS. This is linked to your CA Google account - go to https://chelsea-apps.awsapps.com/start#/ to sign in. From here, you can enter any one of the client accounts you have access to. You will have access to the account for:

• 3 hours (ChelseaAppsDeveloper role)

• 1 hour (Administrator role)

You can also access this page from your Google Apps

For more details, see the AWS section:

AWS

Process

The development process (start to release & feedback).

Overview

1. A ticket containing details for a design/bug/feedback will be created in Asana

   1. Designs will contain screenshots and any details from the designer

   2. Bugs should contain a description of the bug, where it happened, and any steps to recreate (clients often leave bug reports quite empty so you may need to nudge them for more details)

   3. Other feedback may be from anyone, and will contain details of the task

2. The ticket will be tagged as frontend or backend, given a priority level

   1. Focus on tickets with the highest priority level first

3. The ticket will be assigned to a developer

4. The developer will move the ticket to the In Progress column

   1. Keeping the ticket progress up to date helps make sure developers aren't working on the same thing at the same time

5. The developer will pull from the main branch (master or staging), and create a new feature or fix branch locally

6. The developer will build the feature or fix according to the details in the screenshot

   1. When building new features it's always best to check the designs in Framer for the most up to date version first, as tickets may be out dated

   2. If you have any questions, or get stuck, put a comment on the ticket explaining what you've done and what you need, then reassign and move out of the In Progress column

7. Once finished, the developer will check the changes they have made against the ticket, and will run through the app from start to finish to ensure their changes haven't broken anything else

8. The developer will commit their changes with a descriptive message and push to the repo

   1. It's best to commit little and often to help with rollbacks and avoid losing work

9. During the commit, and on the repo, the system will run a series of tests. If any fail, the code will not be able to be merged

10. The developer will open a Pull Request on GitHub

    1. They will set a descriptive title

    2. They will paste the ticket link(s) into the description

    3. They will provide a short summary of their changes, and any notes relevant to their code

    4. They will perform a self review of the pull request and any changes made before opening the PR

    5. They will add comments to any part of the PR that requires more detail

11. The developer will move the ticket from In Progress to In Review

12. The reviewer will then review the code, checking

    1. That the solution fits the requirements in the ticket

    2. That the code is clean, does not perform duplicate logic, handles all edge cases, etc.

    3. That the code is simple to understand (ie. will this code make sense to us in 6 months time)

    4. That the changes work well in all scenarios (e.g. different screen sizes)

    5. That the PR has no conflicts

13. The reviewer will either Approve the PR, or request changes or more details

14. The developer will make any requested changes and resubmit the PR

15. Once Approved, the changes will be merged into the main branch (master or staging)

16. For backend changes:

    1. The CI/CD pipeline will perform a series of checks and run the full test suite

    2. A Docker image will be built and pushed to the repository

    3. The CI/CD pipeline will automatically perform a rolling update to roll out the changes to the staging environment

17. For frontend changes (mobile):

    1. The change will wait on the staging branch until a new Alpha release

    2. The changes will be rolled out according to the project's testing release cycle (daily or weekly) to testing devices (via Testflight)

    3. Once tested, the changes will be merged into the master branch and released under a new version to the App Store

18. For frontend changes (web):

    1. The CI/CD will test the code

    2. The CI/CD will rollout the changes to the staging environment immediately

    3. Once tested, the changes will be merged into the master branch and released under a new version to the production environment

19. Any feedback will be created in a new ticket

Pull Requests

A Pull Request is a request to merge your changes into the staging branch. They will be reviewed by 1-2 other developers who will check the changes and provide feedback.

The aim for Pull Requests is to make them as quick to review as possible, as the longer a PR is open for, the more likely it is to have conflicts or become outdated. To help with this, aim to keep your PRs small and based on one ticket only.

If you have two tickets that rely on each other, do the first ticket in one branch & create a PR, then branch off into a new branch for the other ticket. This means the first PR does not rely on the second, so is more likely to be merged quickly

Environments

For each app we build (frontend and backend), we have 3 environments:

• Development

• Staging

• Production

Development

Each developer has their own environment running locally.

Frontend:

Run the web or React Native server locally on your machine to see changes quick. You can either connect to the Staging API, or you can run your own version of the API locally using Docker (you can also run a database locally if you want a completely clean environment).

Change the API_URL env variable to point to either the staging API URL or a server running on localhost

Backend:

Run the API locally using node (or nodemon) to see your changes. Any changes made can be tested in the local GraphQL Playground or Postman. You'll need to install all the server dependencies, and will need a server .env file (speak to the backend team for this). You can either use the staging database, or you can host your own database locally (usually Postgres or MongoDB).

Change the DB_HOST env variable to point to either the staging database or a locally hosted one

Staging

The Staging environment is used to host changes waiting to be deployed to Production. All changes will be automatically deployed to the staging environment (except mobile apps).

This is where the team will check any changes for bugs. The client usually also has access to this so they can see and check changes before releasing to their customers.

This environment has it's own server/cluster and database, both of which can be used by developers locally to avoid running the server and/or database on your own machine. It's also more likely to be unstable, as it is used as a canary for any issues and has less resources.

Staging apps are usually hosted on testapp.domain.com, with staging APIs on testapi.domain.com.

Production

The Production environment is what the customers see and use. Changes released to here are all given a version number to track bugs, and no changes are released unless they have been tested in the Development and Staging environments.

This environment has it's own server/cluster and database, both with more resources, redundancy and backups than the Staging systems. These systems are also locked down much more tightly.

This environment also has more logging and monitoring enabled so we can detect any issues.

It is not possible to connect to the Production database from your local machine. You can only connect to Production DBs from inside the VPC.

Branching

Staging branch: Staging environment

Master branch: Production environment

When working on a fix or a feature, pull from staging first to ensure you're up to date.

Create a new branch in the format [type]/[name] where type is feat or fix, and name is a descriptive name for the issue.

$ git checkout feat/new-checkout-flow

Never push directly to the master branch

Things you'll need to know

Our tech stack is pretty similar across projects, with a few small differences depending on the needs of the project