Can you guarantee everyone knows your team's best practices and conventions? Probably not, but CodeSee Code Automation can help. Sharing knowledge has always been challenging. Add distributed and remote development teams, and you're facing a monumental task.  

CodeSee watches as your code changes, and alerts developers before those changes are merged with: reminders, checklists, warnings, and/or assigning exactly the right team to review. Now you can reliably enforce processes and scale knowledge sharing--without annoying your developers. Here are 25 ideas of Code Automations that you can implement on your team.

💡
Pro tip! Have you ever given (or received) the same feedback on multiple reviews? Automate that feedback as a helpful comment or checklist, so you never have to give (or receive) it again.

Prevent Outages

1. Always create/deploy migrations safely

When creating a migration, go through this checklist before merging

  • Condition: File added in folder, folder path starts with, packages/server/migrations

  • Action:

    • Add to checklist: Make sure code works before the migration is run
    • Add comment: ℹ️ Reminder:
      This PR has a migration. Given how we deploy, deployed code must work before the migration is run, and after. Often, it is best practice to make a PR with only migrations and deploy that first.

2. Changing Authorization safely

When you modify the authorization flow, run this test matrix.

  • Condition: File path, matches glob, packages/server/app/auth/**
  • Action:
    • Add reviewer: @SarahEngLeader, Please double check this change to auth
    • Add comment: You have made a change to authentication. You must take extra care for our users and their security.

3. Changing Billing Flow safely

When you modify the billing flow, run this test matrix.

  • Condition: File path, matches glob, packages/server/app/[qr]*/**/billing*
  • Action:
    • Add reviewer: @JoeMoney, Please double check this change to billing
    • Add comment: You have made a change to billing. You must take extra care for our users and the business.

Onboarding

4. How we structure new models

When you create a new model, follow this checklist.

  • Condition: File path, matches glob, app/models/**
  • Action:
    • Add to checklist: You created a new model. The best practice was followed

5. How we structure new components

When you create a new component, follow this checklist.

  • Condition: File path, matches glob, lib/components/**
  • Action:
    • Add to checklist: You created a new component. The best practice was followed

6. How we structure new controllers

When you create a new controller, follow this checklist.

  • Condition: File path, matches glob, app/controllers/**
  • Action:
    • Add to checklist: You created a new controller. The best practice was followed

7. How to harden a service

When you create a new service, follow this checklist.

  • Condition: File is added in folder, matches glob, app/service/**
  • Action:
    • Add to checklist: Is all data encrypted at rest?
    • Add to checklist: Is all data encrypted in transit?

8. How we create new packages (npm example below)

When you add a new package, follow this check list.

  • Condition: File path, equals, scripts/ci/publish-npm.sh
  • Action:
    • Add comment: ⚠️⚠️⚠️ DID YOU ADD A NEW NPM PACKAGE??? ⚠️⚠️⚠️ If you added a new npm package you MUST publish it manually first before this script will work!You also need to update our build cache files. Follow the checklist:
    • Add to checklist: Update the build cache for tests: .github/workflows/nodejs-build-test.yml
    • Add to checklist: Update the build cache for release: .github/workflows/release.yml
    • Add to checklist: Publish the npm package manually
    • Add to checklist: update the yarn:build and similar scripts in /package.json to build this package
    • Add to checklist: update the /scripts/build.sh script to build this package when appropriate, and make sure it is build in the correct order (after its dependencies but before the packages that depend on it)

9. New Endpoint checklist

When you create a new endpoint, follow this checklist

  • Condition: File path, matches glob, routers/*.ts
  • Condition: If new code, contains, .post(
  • Action:
    • Add to checklist: Make sure your new endpoint handles CORS correctly
    • Add to checklist: Double check authorization is correct
    • Add to checklist: Double check authentication is correct

Refactoring

10. Block code changes during a refactor

Prevent other developers from making conflicting changes during a refactor.

  • Condition: If new code, contains, [function name]
  • Action:
    • Add to checklist: The function [function name] is being refactored as part of [project name]. Don’t use this function. Use [new function name] instead.

11. Post-refactor maintenance

Now that you've completed a refactor, make sure things stay refactored.

  • Condition: If new code, contains, [function name]
  • Action:
    • Add to checklist: The function [function name] is has been refactored as part of [project name]. Make sure you [step 1].

12. Deprecated functions

This function is no longer used; ensure your team uses the new function.

  • Condition: If new code, contains, [function name]
  • Action:
    • Add to checklist: The function [function name] is has been deprecated as part of [project name]. Make sure you [step 1].
    • Add comment: Want to know more. Check out the DEVELOPER.doc.

Security

13. Dont commit private keys

Seriously, don't commit private keys

  • Condition: If new code, contains, -----BEGIN RSA PRIVATE KEY-----
  • Action:
    • Add to checklist: You’ve committed a private key to the repo. This is BAD.
    • Add to checklist: Remove the private key and contact the security team. This key needs to be rotated.

14. When to ask for a security review?

PR requires a security review

  • Condition: File path, matches glob, auth/**
  • Action:
    • Assign Review: @security, This PR touches auth. Please complete a review.
    • Add to checklist: Complete security review

15. Soc 2 requirements for new services

Follow the Soc 2 requirements process whenever a new service is added.

  • Condition: If new code, contains, [function name]
  • Action:
    • Add to checklist: The function [function name] is has been deprecated as part of [project name]. Make sure you [step 1].
    • Add to checklist: The data must be encrypted at rest
    • Add to checklist: The data must be encrypted in transit
    • Add to checklist: Make sure you have integration tests
    • Add to checklist: Enable security scanning through [SuprSecur]
    • Add comment: Want to know more. Check out the doc link.

Best practices

16. Check if changes occur between version one and two of a system

If there’s a new payment system you are developing ensure that the tech lead reviews every change

  • Condition: File path, matches glob, app/payments/*
  • Action:
    • Add comment: This function is important to [feature name]. Check if there are changes between version 1 and version 2.

17. Don't ship console logs into production

Not shipping console logs are a best practice.

  • Condition: If new code contains console.log
  • Action:
    • Add to checklist: Did you mean to check in that console log? You probably didn't so probably should remove.

18. Avoid index files

Not shipping console logs are a best practice.

  • Condition: File added in folder, folder path starts with, /packages
  • Condition: File name, matches glob, index.[jt]s*
  • Action:
    • Add comment: It looks like you added a new index file. We try to stay away from that pattern because it creates a layer of indirection. Suggestion: if it makes sense, rename that file to something more specific so that people can jump between code files easily.

19. Frontend Route Checklist

What to do when you add a new front end route

  • Condition: File name, equals, react-routes.ts
  • Action:
    • Add to checklist: Ensure /packages/server/app/server.ts exposes these frontend routes on prod
    • Add to checklist: If your route includes the :billingAccountId param, be sure to wrap the component it exposes in routes/index.tsx in a PageProviders component.

20. Remind Folks to compile the code

We should probably compile our code

  • Condition: File path, matches glob, src/*
  • Action:
    • Add comment: Make sure you have compiled the action using ncc. See DEVELOPER.md for details.

21. Remind Folks to update the docs

We should update the doc if this function changes

  • Condition: File path, matches glob, src/*
  • Action:
    • Add comment: This function is important to [feature name]. Make sure you update the doc. See notion.com/.md for details.

Performance

22. Monitor performance

If this file is changed, it degrades performance.

  • Condition: File path, matches glob, src/*
  • Action:
    • Add comment: Make sure you have compiled the action using ncc. See DEVELOPER.md for details.

23. Know if a GitHub Workflow changes

If this workflow is changed, it will affect performance.

  • Condition: File added in folder, folder path starts with, .github/workflows
  • Action:
    • Add comment: Make sure you have compiled the action using ncc. See DEVELOPER.md for details.

Questions for more ideas

24. Critical part of the codebase must be reviewed by "Dave"

PR requires a critical review

  • Condition: File path, matches glob, cart/**
  • Action:
    • Assign Review: @DaveTheSeniorEng, This PR touches cart flow. Please complete a review.
    • Add to checklist: Complete critial flow review

25. Error prone part of the codebase must be reviewed by "Joanna"

PR touches code that only a few people understand.

  • Condition: File path, equals, path/to/error-prone.ts
  • Action:
    • Assign Review: @JoannaIsTheExpert, This PR touches error-prone.ts. Please complete a review.
    • Add to checklist: Complete error prone review