Development Workflow
Here you can find all the steps you should follow for a happy development workflow.
Before starting anything, make sure you start the relevant PT story. The ideal scenario is that each developer isn't holding more than one active task at a time, so we can always at a glance see what each person is working on.
You can either use git-flow for this by using git flow feature start name_of_my_feature (recommended) or manually. If you're not using git-flow, make sure that:
- Your develop branch is up to date (git fetch && git checkout develop && git pull --rebase origin/develop)
- You create the feature branch with the correct naming (git checkout -b feature/name_of_my_feature)
You can either use git flow: (git flow feature publish name) or manually (git push origin feature/name)
As soon as you create a branch, go back to Pivotal Tracker and add a comment in the lines of: Feature branch: feature/name_of_my_feature
Now you're all set to start some hardcore coding!
This part is pretty straightforward. You are blasting commits away, pushing to the remote branch as soon as you commit for backup reasons.
Especially for the Ruby part, it's important to cover the code with tests to prevent regressions. Here's what we're using in a nutshell:
TODO: add testing framework details
There's no silver bullet here but try to aim for having at least one test per public method for normal classes.
Controller specs are more like our integration tests, try to cover at least the basic scenarios such as, different roles, authenticated or not, etc.
We have a Travis CI set up to run tests for each commit you push to the remote repository
TODO: Talk about acceptance servers
It's recommended that sooner rather than later, you open a Pull Request with a [WIP] tag so the other developers can track easily in GitHub the progress of the story. The first line of your pull request should be a link to the PT story this refers to.
Don't worry too much about the body of the PR at this point.
What you should worry about though is the base branch that this PR points to. GitHub points all PRs to master by default and we don't want that when using git flow. Make sure your PR points to develop branch.
Once you created the PR, copy the link and go back to your PT story and paste it as a comment so we have links both ways. Easy peasy.
Once you feel like you're done with your feature, it's time to go back to the PR and fill out the details.
This is the point when you finish the story in Pivotal Tracker. It means you are basically done with the development, but haven't delivered it yet.
Generally speaking, your PR should have the following:
- A PT link at the top
- A basic description (more developer oriented vs. the PT story macro level)
- A Changelog
- A basic recipe on how to test this feature (if applicable)
Example of a completed PR:
Once this is done, paste the PR link to our Hipchat room so the other developers get a chance to review / comment on it.
A rule of thumb is to leave the PR open for a day to give a chance for everyone to review / comment on it. Developers can (and should) comment on specific lines of code in order to improve the general code quality.
Once everyone is happy - including the CI - this can be merged from GitHub and the feature branch can be safely deleted.
It's important to note that in general you shouldn't merge your own Pull Requests as it kind of defeats the point of peer review.
Every time a PR gets merged to develop, it's time to deploy to our staging environment.
This is the point when you deliver the story in Pivotal Tracker. It means it's now waiting for tests in our Staging environment. It could be either accepted or rejected by the PO.
By the end of each sprint at the very least, we're going to create a new release. This is done by using the following git flow command: git flow release start version_name
This will create a release/version_name branch based from develop, essentially freezing the code at that point in time.
Last minute fixes should be pointed to this branch using the same workflow described before (but opening the PR to this branch instead of develop).
Once everyone is happy about the release we can merge it to master by using the following command: git flow release finish version_name
This will merge it to master, merge any further changes back to develop and tag master with the version name (this is why you should be using git flow 😄)
TODO: Document deployment shenanigans
cap staging deploy -s branch=develop