-
Notifications
You must be signed in to change notification settings - Fork 0
Development Process
This wiki page will give you a basic understanding and flow of the development process we wish to implement for this project. If you have any questions, comments, or concerns please contact one of the project owners and we will do our best to address it for you.
Pick up your ticket! Go to Projects -> Development and grab the top item in the queue that matches the following requirements.
Acceptable work items:
Contain a user story - Basic "As X I want Y/To do Z/..."
Contain detailed acceptance criteria - "For this ticket to pass you must cut an orange in half" ... Is a bad example. There are several ways you can approach this ticket that may not be intended. "Orange cut in half vertically, peel is still on, used a knife, etc. etc..."
If the top ticket does not meet those basic requirements contact a PM and move on the the next item.
Create a new branch, off of master, with the name of your ticket ex. DCV1-0000 would be the first branch name.
Useful commands (if you are not using the UI of the IDE):
git checkout DCV1-0000 -> Checks out the branch
git checkout -b DCV1-0000 -> - Creates a new branch and checks it out
git branch -> Creates a new branch
git status -> Check if you have the right branch, if commits are staged, etc...
We can start developing... right? This depends on the type of ticket you had just picked up. If the ticket you have is implementing a story it is encouraged to create regression/g-unit tests before starting. If you are doing a bug fix for a public function IT IS MANDATORY TO WRITE TESTS. (Test-Driven-Development)
Development! This part you guys have got. Implement the actual contents of your ticket! Easy! It is encouraged to get code reviews all throughout the dev stage - not just at the pull request.
Useful commands (if you are not using the UI of the IDE):
[python]/[py] -m SimpleHTTPServer <Port> -> where <port> is the port you want, this lets you view your changes on a server called http://localhost:<Port>
git add <file> or git add . (all) -> Adds the file(s) into a commit.
git commit [-a] [-m] -> Stages (gets it ready for a push) the commit. [-a] lets you add ALL the files without 'git add .' [-m] lets you include a commit message without having to use the cmd text editor. (ie. git commit -a -m "DCV1-0000: initial commit)
git push origin <Branch> -> pushes the commit to the branch on github
Ticket is implemented... hopefully. Have you THOROUGHLY tested the item? We do not have a "formal QA process" this is the step to ensure your ticket is 100% implemented and tested. Nothing gets merged into master that YOU are not 100% confident in.
Basic testing: UI Change - Is everything visually appealing? Are there any "glitches" as part of your changes? If it's an input field is there validation constraints and did you do negative testing on it?
Code Change - Is it a public function - did you write unit tests? If it's a private function did you/could of you created a regression around the scenario it get's triggered?
We are almost ready to do our pull request. Before doing so make some screen shots of your changes if anything is visual. If there isn't visual changes spend some time writing up what you did an why.
Think your code is ready for review? It's time to but it on the chopping block. To create a pull request on Github, navigate to your branch via https://github.com/umdevclub/umdevclub.github.io -> branches and then click Create Pull Request. If your change is a front end change, it is IMPORTANT to attach some screenshots of what you did so the reviewers of the PR know what to look for. This will speed up the workflow immensely AND it tells us you have done some testing.
It is YOUR responsibility to answer any questions about your decisions in the code change as well as fix anything that needs to be fixed in a timely manner. We don't want your branch to grow stale and force a redo of your work. Once everything has been fixed and approved by at least 50% of your peers + 1 Project Owner, it will be merged by the project owner and you will see your changes on umdevclub.github.io. When it is fully tested the changes will then be pushed into umdevclub.com