Use case

Use case

During development cycle, developers often introduce rake tasks for data migration, and those rake tasks have to be run during the release process. There may be tens of those tasks, you may have different environments - keeping track of which task will have to be run where and when they were eventually run might be extremely tedious. My team had a spreadsheet document for every release where we would add those tasks. But without any automation it becomes messy pretty quickly.

Development workflow with Traker

If you worked on a feature, and introduced migrations in PR, you need to add those migrations to the corresponding sections in .traker.yml file. Let's say the task dataload:load_fixtures has been added as part of PR, and this task can only be run once in dev and stg environments, your diff in .traker.yml in this PR would look like this:

environments:
  dev:
    # ... some other tasks above
    - name: dataload:load_fixtures
      notes: can be run only once    
  stg:
    - name: dataload:load_fixtures
      notes: can be run only once, may take very long on stg

There are a couple of rules when adding entries to the yaml file:

1. Entries should only be appended to the end of the list
2. You can have a couple of entries with the same name
3. Keep notes short

Release engineer workflow with Traker

1. Use git diff on .traker.yml file to determine which tasks were introduced for the release.
2. Make sure TRAKER_ENV is set in the environment you are running tasks against.
3. Run rake task as usual.
4. Check rake task's status by querying traker_tasks table in the database (or Traker::Task in rails c).

Currently we are on very early stages of Traker development, and we want to keep it as simple as possible, so most likely schema of the yaml file will be changed in future to something more sophisticated and polished.