Software development workflow

  • Changes to the core software are developed in feature branches.
  • Once a feature is complete, the change is proposed for a merge into the staging branch.
  • Changes are not merged until the CI system can verify:
    • Test coverage will not drop by merging the branch
    • There are no type errors or compilation warnings at build time
    • All unit and integration tests pass
  • After CI checks pass, the changes may be merged by a maintainer.

Production release workflow

  • Once a pull request is merged into the staging branch, it is automatically deployed to a staging server for manual QA testing.
  • After determining that there are no deficiencies noted in the software, a deploy is scheduled.
  • A pull request from the staging branch is proposed to the master branch.
  • A team member (not the same person proposing the pull request) must review changes prior to merging into master.
  • After merging, a new release is tagged (see: Release Naming Conventions).
  • Prior to a production deploy, the developer team must ensure that Heroku has created a recent database backup.
  • The software is deployed to the production server via Heroku CLI
  • Database migrations are performed as needed.
  • A “health check” is performed on the server.
  • Occasionally, a full dyno restart is performed (as needed).
  • Manual QA checks are performed on a production FarmBot device to ensure the deploy succeeded.

System health checks

The following checks should be performed regularly to ensure the system is running as intended:

  • Checking error reporting tools (Rollbar, Skylight) for new and unknown runtime exceptions.
  • Ensuring that scheduled database backups are actually happening.
  • Checking memory usage of RabbitMQ nodes
  • Checking skylight for extremely slow HTTP endpoints.
  • Running npm outdated and bundle outdated to find old dependencies.
  • Checking Github security alerts for vulnerable dependencies.
  • Checking the FarmBot forum for service interruptions and bug reports
  • Checking the database for throttled devices (a sign of possible firmware or FBOS bugs)

Release naming conventions

The project loosely follows semantic versioning practices. Occasional, breaking changes outside of the package will trigger a major version release. An example would be performing a major version bump on the API to match a major version bump in FarmBot OS.

Every major version receives a “code name”. The code name is collectively determined at the time of release by team members. The code name adheres to the following rules:

  • A code name is comprised of two words.
  • The first word is an adjective.
  • The second word is the name of a plant.
  • Both words must begin with the same letter.

Past release names

  • v7: Happy Hibiscus
  • v6: Gracious Guava
  • v5: Fantastic Fern
  • v4: Emergent Echinacea
  • v3: Deciduous Daffodil
  • v2: Conic Cactus
  • v1: Adventive Acacia