Developer guidelines

Existing projects

Tasks are tracked as issues in https://github.com/orgs/ror-community/projects/3
Staff from DataCite/CDL/Crossref should work directly on repositories in https://github.com/ror-community . For write access, contact tech lead. External developers should fork repositories into their own Github accounts.
Make changes on a local feature branch. Always branch from dev.
Test all changes locally (local dev setup instructions are provided in each project's readme)
For long, complicate projects use feature flagging. We use LaunchDarkly to manage feature flag status and coordinate front and back end flags.

Push changes to remote feature branch and open pull requests against dev. Do not push directly to main/master, staging or dev!
Assign pull requests to tech lead for review.
Add the pull request link to the issue in https://github.com/orgs/ror-community/projects/3 and move it to the submitted column.
After merge, delete your feature branch (Auto-delete can't be used because it deletes staging/dev branches)
Do not delete staging or dev branches!

All changes are tested on dev by tech lead before deploying to other environment
For large change sets, ask ROR team for help testing (message ror-core in Slack)
For major projects that have a large impact on users (new schema versions, new services, etc), a community beta test period should be conducted. These are usually conducted in dev environments because staging is actively used as part of the data deployment process. Coordinate beta test with ROR team.

Deployment is generally done by the tech lead.

Each project has main/master, staging and dev branches which deploy to prod, staging and dev environments via Github actions
Dev and staging branches are deployed on merge; main/master branch is deployed when a new release is published
Dev deploy: merge feature branch to dev
Staging deploy: merge dev branch to staging branch
Production deploy: merge staging branch to main/master and publish a release

Developers should update user documentation in https://ror.readme.io when functionality is added/changed
All changes should be summarized in Github releases, ex https://github.com/ror-community/ror-api/releases/tag/1.6
Changes that have significant impact on users should be summarized in the Changelog https://ror.readme.io/changelog and announced on the ROR Tech Forum Google Group. Changes can optionally be shared with other lists - coordinate with ROR team.

Each new project should have a repository in https://github.com/orgs/ror-community . Repositories should be public; sensitive info should never be committed to Github.
Include a readme with instructions for running locally. List all pre-requisites, such as software/packages needed.
Create dev and staging branches for all new projects. Make initial commits to dev.
Apps that can't be run from static files should be containerized using Docker. Provide docker-compose file for running locally
All apps must be configured to run in multiple environments (dev, staging, prod). Use environment variables to inject appropriate URLs, API endpoints, etc.
Do not store sensitive info in code. For projects that use .env files, commit an example .env file, then .gitignore it to prevent exposing sensitive info.
Include Github Actions files to deploy to dev, staging and production from dev, staging and main branches. Dev and staging should deploy on merge; main should deploy when a release is published.
Any new infrastructure should be provisioned using Terraform in new-deployment. See ROR infrastructure for more info on infrastructure.