As we add more and more code to the project, we must agree upon some basic rules to avoid stepping on each other's work. There are tools in place to make this easier (e.g. Git, linters,TravisCI, etc) but at the end of the day, it’s all about communication. If in doubt, use one of the communication channels to talk to someone.
Think of it like hitting save. Your last commit for the feature/fix/etc should be VERY detailed. Don’t use -m for it. Write a subject line (a single sentence summary of what you did), followed by an empty line, followed by a paragraph describing what you solved/fixed, followed by an empty line, followed by a paragraph describing how you solved it. Follow this format strictly for the last commit. This makes the code changes amazingly traceable using git blame (e.g. someone can see who changed a given line, when, why, and how).
Think of it like copy-pasting the source code into a new folder. Branches are very lightweight and an amazing way to isolate different works. Don’t be afraid to have many branches; you can quickly delete them if you need to. By using branches to isolate your work, you can avoid merge conflicts for the most part. Here are a few rules related to branches:
-
Name your branches using the following format: theme_area_firstName. The theme should be something like bugfix or refactoring. The area should be more specific to what you are fixing, refactoring, etc; e.g. viz or data. And, ofcourse, the firstname should be your first name.
-
You can’t push to the branches master and development. You need to make a pull request and at least 1 person needs to review and approve it, and TravisCI must green light it, before it gets merged into either of those branches. This is because master should always be stable and development should be stable enough for us to branch off of when we do work.
-
Related to (2) above, use the Git Workflow. Branch off of development, do your work, write your unit tests, then push it to Travis to get the green light. If you are working with someone else on the same problem/feature, you should create a different branch to combine your works once you both finish working on your own and handle your merge conflicts there. Then make a pull request from the combined branch into development. Pull request into development only only the scrum master should directly touch the master branch.
Issues are the team’s todo list. Once we decide on a user story, we can break it down into issues and move it GitHub. Issues make it really easy to discuss code, progress, and larger goals. For example, if you have a line like Issue #12 in your commit, GitHub will link that commit in the issue comments. GitHub also provides a board for Agile development. All new issues go into the Backlog. When we decide to work on a given issue, we move it into Todo. It’s then moved into In Progress once someone starts working on it. When the issue is closed, Automation will put the issue into the Done column. This makes it easy to see who’s doing what and how much time we need to finish whatever feature/fix.
You can generate a report for your tests by doing something like
coverage run --source='.' manage.py test
on the same level as 'manage.py'. Then do
coverage html
which generates an HTML report of your code coverage. Open the file 'htmlcov/index.hmtl' in your browser. The folder 'htmlcov' is on the same level as manage.py.