Skip to content

Commit

Permalink
Split protocol document into smaller documents
Browse files Browse the repository at this point in the history
* Extract Git, Rails, and iOS protocols.
* Move Rails-specific code review to Rails protocol.
* Make git protocol less Rails-specific (instead of `rake`, say "run
  tests" so it can continue to apply to iOS, Haskell, etc. projects).
* Nest bullets.
* Use consistent capitalization.
  • Loading branch information
Dan Croak committed Mar 4, 2014
1 parent a9273ca commit 2ccac0c
Show file tree
Hide file tree
Showing 6 changed files with 279 additions and 240 deletions.
3 changes: 3 additions & 0 deletions README.md
Expand Up @@ -4,6 +4,9 @@ Guides
Guides for getting things done, programming well, and programming in style.

* [Protocol](/protocol)
* [Git](/protocol/git)
* [Rails](/protocol/rails)
* [iOS](/protocol/ios)
* [Code Review](/code-review)
* [Best Practices](/best-practices)
* [Style](/style)
Expand Down
21 changes: 3 additions & 18 deletions code-review/README.md
Expand Up @@ -23,7 +23,7 @@ Everyone
* Talk in person if there are too many "I didn't understand" or "Alternative
solution:" comments. Post a follow-up comment summarizing offline discussion.

Having your code reviewed
Having Your Code Reviewed
-------------------------

* Be grateful for the reviewer's suggestions. ("Good call. I'll make that
Expand All @@ -43,7 +43,7 @@ Having your code reviewed
* Wait to merge the branch until Continuous Integration (TDDium, TravisCI, etc.)
tells you the test suite is green in the branch.

Reviewing code
Reviewing Code
--------------

Understand why the code is necessary (bug, user experience, refactoring). Then:
Expand All @@ -58,7 +58,7 @@ Understand why the code is necessary (bug, user experience, refactoring). Then:
* Seek to understand the author's perspective.
* Sign off on the pull request with a :thumbsup: or "Ready to merge" comment.

Style comments
Style Comments
--------------

Reviewers should comment on missed [style](../style)
Expand All @@ -74,18 +74,3 @@ An example response to style comments:

If you disagree with a guideline, open an issue on the guides repo rather than
debating it within the code review. In the meantime, apply the guideline.

Ruby on Rails review
--------------------

* Review data integrity closely, such as migrations that make irreversible
changes to the data, and whether there is a related todo to make a database
backup during the staging and production deploys.
* Review SQL queries for potential SQL injection.
* Review whether dependency upgrades include a reason in the commit message,
such as a link to the dependency's `ChangeLog` or `NEWS` file.
* Review whether new database indexes are necessary if new columns or SQL
queries were added.
* Review whether new scheduler (`cron`) tasks have been added and whether there
is a related todo in the project management system to add it during the
staging and production deploys.
226 changes: 4 additions & 222 deletions protocol/README.md
@@ -1,226 +1,8 @@
Protocol
========

A guide for getting things done.
Guides for getting things done.

Set up laptop
-------------

Install the latest version of Xcode from the App Store.

Set up your laptop with [this script](https://github.com/thoughtbot/laptop)
and [these dotfiles](https://github.com/thoughtbot/dotfiles).

Create Rails app
----------------

Get Suspenders.

gem install suspenders

Create the app.

suspenders app --heroku true --github organization/app

Create iOS app
--------------

Create a new project in Xcode with these settings:

* Check 'Create local git repository for this project'.
* Check 'Use Automatic Reference Counting'.
* Set an appropriate 2 or 3 letter class prefix.
* Set the Base SDK to 'Latest iOS'.
* Set the iOS Deployment Target to 6.0.
* Use the Apple LLVM compiler.

Get liftoff.

gem install liftoff

Run liftoff in the project directory.

liftoff

Set up Rails app
----------------

Get the code.

git clone git@github.com:organization/app.git

Set up the app's dependencies.

cd project
./bin/setup

Use [Heroku config](https://github.com/ddollar/heroku-config) to get `ENV`
variables.

heroku config:pull --remote staging

Delete extra lines in `.env`, leaving only those needed for app to function
properly. For example: `BRAINTREE_MERCHANT_ID` and `S3_SECRET`.

Use [Foreman](https://github.com/ddollar/foreman) to run the app locally.

foreman start

It uses your `.env` file and `Procfile` to run processes just like Heroku's
[Cedar](https://devcenter.heroku.com/articles/cedar/) stack.

Maintain a Rails app
--------------------

* Avoid including files in source control that are specific to your
development machine or process.
* Delete local and remote feature branches after merging.
* Perform work in a feature branch.
* Rebase frequently to incorporate upstream changes.
* Use a [pull request] for code reviews.

[pull request]: https://help.github.com/articles/using-pull-requests/

Write a feature
---------------

Create a local feature branch based off master.

git checkout master
git pull
git checkout -b <branch-name>

Prefix the branch name with your initials.

Rebase frequently to incorporate upstream changes.

git fetch origin
git rebase origin/master

Resolve conflicts. When feature is complete and tests pass, stage the changes.

rake
git add --all

When you've staged the changes, commit them.

git status
git commit --verbose

Write a [good commit message]. Example format:

Present-tense summary under 50 characters

* More information about commit (under 72 characters).
* More information about commit (under 72 characters).

http:://project.management-system.com/ticket/123

Share your branch.

git push origin <branch-name>

Submit a [GitHub pull request].

Ask for a code review in [Campfire](https://campfirenow.com/).

[good commit message]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[GitHub pull request]: https://help.github.com/articles/using-pull-requests/

Review code
-----------

A team member other than the author reviews the pull request. They follow
[Code Review](../code-review) guidelines to avoid
miscommunication.

They make comments and ask questions directly on lines of code in the Github
web interface or in Campfire.

For changes which they can make themselves, they check out the branch.

git checkout <branch-name>
rake db:migrate
rake
git diff staging/master..HEAD

They make small changes right in the branch, test the feature in browser,
run tests, commit, and push.

When satisfied, they comment on the pull request `Ready to merge.`

Merge
-----

Rebase interactively. Squash commits like "Fix whitespace" into one or a
small number of valuable commit(s). Edit commit messages to reveal intent.

git fetch origin
git rebase -i origin/master
rake

View a list of new commits. View changed files. Merge branch into master.

git log origin/master..<branch-name>
git diff --stat origin/master
git checkout master
git merge <branch-name> --ff-only
git push

Delete your remote feature branch.

git push origin --delete <branch-name>

Delete your local feature branch.

git branch --delete <branch-name>

Deploy
------

View a list of new commits. View changed files. Deploy to
[Heroku](https://devcenter.heroku.com/articles/quickstart) staging.

git fetch staging
git log staging/master..master
git diff --stat staging/master
git push staging

If necessary, run migrations and restart the dynos.

heroku run rake db:migrate --remote staging
heroku restart --remote staging

[Introspect] to make sure everything's ok.

watch heroku ps --remote staging

Test the feature in browser.

Deploy to production.

git fetch production
git log production/master..master
git diff --stat production/master
git push production
heroku run rake db:migrate --remote production
heroku restart --remote production
watch heroku ps --remote production

Watch logs and metrics dashboards.

Close pull request and comment `Merged.`

[Introspect]: http://blog.heroku.com/archives/2011/6/24/the_new_heroku_3_visibility_introspection/

Set Up Production Environment
-----------------------------

* Make sure that your [`Procfile`] is set up to run Unicorn.
* Make sure the PG Backups add-on is enabled.
* Create a read-only [Heroku Follower] for your production database. If a Heroku
database outage occurs, Heroku can use the follower to get your app back up
and running faster.

[Heroku Follower]: https://devcenter.heroku.com/articles/improving-heroku-postgres-availability-with-followers
[`Procfile`]: https://devcenter.heroku.com/articles/procfile
* [Git](/protocol/git)
* [Rails](/protocol/rails)
* [iOS](/protocol/ios)
109 changes: 109 additions & 0 deletions protocol/git.md
@@ -0,0 +1,109 @@
Git Protocol
============

A guide for programming within version control.

Maintain a Repo
---------------

* Avoid including files in source control that are specific to your
development machine or process.
* Delete local and remote feature branches after merging.
* Perform work in a feature branch.
* Rebase frequently to incorporate upstream changes.
* Use a [pull request] for code reviews.

[pull request]: https://help.github.com/articles/using-pull-requests/

Write a Feature
---------------

Create a local feature branch based off master.

git checkout master
git pull
git checkout -b <branch-name>

Prefix the branch name with your initials.

Rebase frequently to incorporate upstream changes.

git fetch origin
git rebase origin/master

Resolve conflicts. When feature is complete and tests pass, stage the changes.

git add --all

When you've staged the changes, commit them.

git status
git commit --verbose

Write a [good commit message]. Example format:

Present-tense summary under 50 characters

* More information about commit (under 72 characters).
* More information about commit (under 72 characters).

http:://project.management-system.com/ticket/123

Share your branch.

git push origin <branch-name>

Submit a [GitHub pull request].

Ask for a code review in the project's chat room.

[good commit message]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
[GitHub pull request]: https://help.github.com/articles/using-pull-requests/

Review Code
-----------

A team member other than the author reviews the pull request. They follow
[Code Review](/code-review) guidelines to avoid
miscommunication.

They make comments and ask questions directly on lines of code in the GitHub
web interface or in the project's chat room.

For changes which they can make themselves, they check out the branch.

git checkout <branch-name>
./bin/setup
git diff staging/master..HEAD

They make small changes right in the branch, test the feature on their machine,
run tests, commit, and push.

When satisfied, they comment on the pull request `Ready to merge.`

Merge
-----

Rebase interactively. Squash commits like "Fix whitespace" into one or a
small number of valuable commit(s). Edit commit messages to reveal intent. Run
tests.

git fetch origin
git rebase -i origin/master

View a list of new commits. View changed files. Merge branch into master.

git log origin/master..<branch-name>
git diff --stat origin/master
git checkout master
git merge <branch-name> --ff-only
git push

Delete your remote feature branch.

git push origin --delete <branch-name>

Delete your local feature branch.

git branch --delete <branch-name>

0 comments on commit 2ccac0c

Please sign in to comment.