Repository
Create a new private repository in your chosen hosting platform.
Github, Gitlab, Bitbucket and Azure DevOps are some options.
Repository Branch Permissions
Protect main!
Setup branch permissions to encourage source control best practices. Don't just push straight to main.
Pull Requests
Create pull requests so that your code changes can be well documented and easily reverted if necessary.
Use a pull request template markdown file to set pull request standards. Introduce checklists like:
- Tests added?
- Tested in major browsers? (Chrome, Firefox, Safari)
- Documentation added/updated?
Other useful items to have in PR descriptions:
- screenshots and gifs of the change in functionality
- detailed reproduction steps
Automated Code Review
It may also be useful to use bots to automate common code review chores to let your Developers focus on the crux of the pull request. Danger JS is a useful tool for this.
Continuous Integration / Continuous Deployment
Setup CI / CD pipeline(s) so that when you push code to your repository your linting, tests and security audit tools run.
It is recommended to run your pipeline steps when:
- a PR is created
- code is pushed to a PR'd branch
- a PR is merged
- deploying to an environment (Dev, Staging, Prod)
Running too frequently such as any time code is pushed to a non-PR'd branch can unnecessarily cost you in CI build credit.
Environments
It is recommended to have at least 2 environments (Staging and Production). Ideally you will also have a deployed Development environment that developers feel comfortable pushing code to in order to test.
Secrets/Keys
Store secrets such as API keys in a .env file that isn't pushed to your repository. You can add it to your .gitignore file.
Set the environment variables in your CI/CD environment which will be interpolated at deploy time.
Agile Processes
Work in a way that works for your team and iterate on your processes each sprint.
Cultivate an environment where people feel comfortable speaking their mind and offering new ideas. Try things out and don't be scared of change.
Setup a board that you can work from. Set columns that work for you. E.g. Backlog, In Progress, Testing, Completed.
Linting
Taking steps to ensure your code is consistent and everyone in your team has the same setup can save time in code review.
Nit-picking indentation and code style can be taken out of the equation with linting.
ESLint and Prettier are commonly used in JavaScript projects and provide excellent default configurations that can be tweaked easily with an .eslintrc file and rules statements.
Rubocop is commonly used in Ruby projects.
Guides
Code style - JS, SASS, Ruby
Whatever the language, create a guide on code style so that everyone in the team is on the same page.
Testing
A testing guide can be useful as it lets the team know what and when to write tests. Are you a TDD-based team? Write that in your guide and instruct new developers on how to do it.
If you find a bug, write a test for it to ensure it doesn't happen again.
