Feature workflow - iToto/developmentCycle GitHub Wiki

Below you’ll find the proper way to go about implementing feature requests in our work environment. This workflow can be adapted to your personal work habits but please remember you are working on a team and any changes you make to this workflow have to be compatible with the team’s vision for the project.

A new Redmine issue comes up requesting some new kind of functionality (or sometimes a change to existing functionality) in your project. Your first step should be to read what they wrote.

A feature request should have all of the following:

1. Description of desired functionality (including comparison to existing functionality if relevant)
2. Affected version(s)
3. Desired steps
4. Data that can be used to develop with
5. Contact information
6. Priority
7. ….

Things you should consider:

1. Is this a bug or a feature? – We’ve often noticed that some users believe the software should work a certain way and if it works differently, then it’s a bug. Many times this is just a request for something new. If that is the case, re-categorize the issue and move on (be ready for backlash).

This is when you open a text editor. Look at code. See what needs to be done.

Your customer has in their hands a particular build. You need the code that they are running. Look at what build they have and get the code from there, chances are you’ll want to checkout a particular git branch.
For example:

git checkout master

Next you want to make a branch for your bug fix.

git checkout -b issue#

You’re now on a new branch named after your Redmine issue. You can really name your branches whatever you want, but when we look at merge commits it’s a bit easier to search by issue#.

You should try splitting the task into as many steps as possible. Each step should get its own Redmine issue that is a subtask of the original bug. Use the tracker type Task.

“Test? I haven’t written any code yet!”

You know what is expected to happen. Write a unit test that gives your bad code input and checks that the right output is given. (this step should have its own Redmine issue).

This is how you go about doing that

Git is all about short lived branches. You’ll want one for each sub-task you create in Redmine related to any coding you’re going to do.

That’s it!

A basic unit test’s data consists of two things. Inputs and valid outputs. You’ll need various examples of different kinds of data you’ll get. You should even include invalid inputs that might come up from bad csvs that customers try to load.

Write a test that takes your input, passes it to your buggy code and then reads what comes out. That’s all your unit test has to do.

You can learn about staging by reading the manual.

Again…rtfm

Your commit message should be meaningful. Seriously. If you write a commit message with something like I made some changes you will be mocked.

Your message should:

1. make reference to the Redmine issue#
2. describe what you wrote

That’s pretty much it.

If you did something particularly complex in your commit, you can describe it in your pull request

Next step is to merge your unit test code into your feature fix branch.

Now it’s time to actually make changes to the program’s code.

If you haven’t already, log another Redmine issue for your code changes.

Create a git branch for the new issue you’re working on.

…

You made a unit test for this, give it a shot! If it fails, fix the problem.

You know how to do this because you’ve ready the rest of this guide!

Easy peasy lemon squeasy.

The rest of the workflow follows the same steps as the bug fix workflow