Skip to content
Cody Mingus edited this page Mar 26, 2014 · 13 revisions

This page serves as a guide on how code a feature from start to finish in a way that will ensure your code is stable, readable, maintainable and doesn't interfere with the work of others.

Summary

This is a summary of what you should do when coding a new feature (doing a rally task). The real details are explained in the steps below.

  1. Assign yourself a rally task
  2. git checkout master
  3. git pull
  4. git checkout -b TA###NewFeature where the ### is the task id of the rally task.
  5. Code and test your feature
  6. Run the build script
  7. Fix anything that build script complains about then go back to step 6.
  8. git status
  9. Use git add and git rm to include desired additions and deletions in your next commit.
  10. git commit -m 'Descsription of what changed with this commit'.
  11. git push
  12. Create a pull request on GitHub.
  13. Address things brought up in code review.
  14. Go back to step 8, but skip step 12 when you get to it. The pull request has already been made. Keep doing this until the branch has been merged.

Step 1: Getting a Small Task

Select a task from Rally and assign it to yourself. If you feel like it may take more than ~100 lines of code to do this task, consider breaking it into smaller tasks, and then assign yourself to one of the smaller ones. Keep doing this until you have a task that should end up being around ~100 lines of feature code and ~100 lines of test code.

Step 2: Get the Latest version of the code

Enter the repository (via bash, GitHub app, Eclipse, or whatever) and switch to the Master branch. Pull the latest version of Master from the central repository. Directions via the command line are shown below:

git checkout master
git pull

Step 3: Make a new branch

From the master branch, create a new branch. You can check what branch you are in using git branch. The branch name should begin with the TaskID. For example, if there was a task to create a build script, and the TaskID was TA34, the branch that it is created on should be called something like TA34CreateBuildScript. In Rally, mark the task as In-Progress. To create this branch from the command line, we would type git checkout -b TA34CreateBuildScript.

Step 4: Code and Test your Feature

In this part you actually do what the task describes. It's recommended that you use test driven development here, but it's not required. You should commit at good milestones (like you just finished writing a method and have one more to go). It's also a good idea to run ant before each commit. Make sure that the feature gets fully coded and tested unless some sort of roadblock shows up.

Step 5: Make sure your code passes the Build Verification Test

Once you're done coding run the build script to make sure your code is well tested and well formed. You can run the build script by navigating to the root directory of the repository (AutoAutoTest) and running ant. Ant will then find and run the build script, and complain about any problems that may have been introduced into the build. Fix everything it complains about, then run ant again. Keep doing this until it doesn't complain about anything anymore.

Step 6: Push your changes to the main repository

Make sure that all of the changes due to the build script are committed. Then push your branch to GitHub. This can be done from the command line with git push. Git may give an error an tell you to run a different command. If it does, run that command instead.

Step 7: Request a code review

Using your favorite web browser, go to the AutoAutoTest repository on GitHub's website. On this page there should be a message saying you recently committed a branch and it should have a button that allows you start a pull request.

If not then on the right, you'll see a button for pull requests. Click that button. Click the new pull request button. For the first branch, pick master. For the second, pick the branch you created for this task. Give the pull request a description.

Step 8: Wait for code review

Hopefully someone else will eventually get around to reviewing your code. If the code reviewer makes a comment, either make the change request or explain to the code reviewer why that change should not be made. Keep doing this until the reviewer is happy with your code.