Articles in this section

Development Workflow (DRAFT)

Avatar
Permanently deleted user
Updated
Follow

The development workflow features:

before a feature enters the development team.

  1. Product owner writes features in aha.io

  2. Product designer writes an epic for each feature

  3. Product Designer writes scenarios inside Stories and groups them into Epics.

  4. Tester reviews and adds to scenarios

The feature enters the development team.

  1. In the Scrum sprint planning stories are estimated by the development team.
  2. At the end of the planning meeting the stories are prioritized by the Product Designer

  3. Developer takes ownership in the story and starts work (write integration test) on a Story and clicks 'Start'. If during development another developer takes over, that person takes ownership

  4. Devloper starts a gitflow 'feature' 

  5. When the story is finished (all tests pass) in Pivotal clicks 'Finish'.

  6. After development of the feature is finished the developer creates a pull request to the develop Branch inside BitBucket. Tick the 'close branch after merge' box. One or more relevant reviewers are added. Explain the changes in the description of the PR. 

  7. The Developer who has reviewed / approved will merge the change to the Develop branch, this closes the feature branch. 

Release workflow TBD

  1. When all the stories have finished and merged in to develop branch, the developer that reviewed the last story merges the Epic branch into Master. The Epic branch is closed. At this point the changelog.txt in the root of the project is appended with a commit description per story inside the EPIC.

  2. After changes have been pushed to the test server and the tests have run successfully, he will click 'Deliver' on all stories.

  3. The product owner can then review the changes on the testing server and either 'accept' or 'decline' on individual stories.

  4. Decline must be accompanied with clear comments as to why it was declined.

  5. When a story is declined, the responsible developer will review the comments and revise the changes and follow the procedure from #2.

COPIED FROM Google Sites: 

The development workflow features:

  1. Product Owner writes scenarios inside Stories and groups them into Epics.

  2. Developer takes ownership in the story and starts work (write integration test) on a Story and clicks 'Start'. If during development another developer takes over, that person takes ownership

  3. If the epic does not has a Epic Branch, for the project, the developer creates the branch with name of epic with underscores (snake_case) starting with 'epic_'

  4. The developer will create a new Story Branch for this individual story. The name must be story title in snakecase.

  5. When the story is finished (all tests pass), the code is handed over to a reviewer, in Pivotal clicks 'Finish'.

  6. After development of the feature is finished the developer creates a pull request to the Epic Branch inside BitBucket. Tick the 'close branch after merge' box. One or more relevant reviewers are added. Explain the changes in the description of the PR. Squash all commits with rebase and write an accurate description of what has been done. http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

  7. The Developer who has reviewed / approved will merge the change to the Epic branch.

  8. When all the stories have finished and merged in to epic branch, the developer that reviewed the last story merges the Epic branch into Master. The Epic branch is closed. At this point the changelog.txt in the root of the project is appended with a commit description per story inside the EPIC.

  9. After changes have been pushed to the test server and the tests have run successfully, he will click 'Deliver' on all stories.

  10. The product owner can then review the changes on the testing server and either 'accept' or 'decline' on individual stories.

  11. Decline must be accompanied with clear comments as to why it was declined.

  12. When a story is declined, the responsible developer will review the comments and revise the changes and follow the procedure from #2.

The development workflow isolated issues / stories:

  1. Product Owner writes the scenario inside Story (bug or isolated change).

  2. Developer takes ownership in the story and starts work (write integration test) on a Story and clicks 'Start'.

  3. The developer will create a new Story Branch for this individual story or use the bug_fixing branch. The name must be story title in snakecase prefixed with 'bug_'.

  4. When the story is finished (all tests pass), the code is handed over to a reviewer, and the developer clicks 'Finish'.

  5. Squash all commits with rebase and write an accurate description of what has been done. http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

  6. The Developer who has reviewed / approved will merge the change to Master branch.

  7. After changes have been pushed to the test server and the tests have run successfully, he will click 'Deliver' on the story.

  8. The product owner can then review the changes on the testing server and either 'accept' or 'decline' on individual story.

  9. Decline must be accompanied with clear comments as to why it was declined.

  10. When a story is declined, the responsible developer will review the comments and revise the changes and follow the procedure from #

How to face change in DB:

 

First, it is useful read this document where doctrine devs advise how to use the library to face this problems.

If there is not any way to keep or extend the structure, and we are sure to have to change Db structure the procedure is:

 

1. Create a DB script in api migrations folder with a identifying name

2. Create two scripts(up and down) in order to allow rollbacks.

3. Test deploy and rollback with the script created.

4. Specify inside body commit the necessity of running this script. Look our doc about git here.

 



Git deployment workflow with BitBucket:

 

create a cb_deploy repository that holds all the deploy scripts to make sure we all have the same scripts.

phase 1:

  1. rsync exclude files for all

  2. well commented deploy scripts

  3. this section in README.md

  4. scripts deploy_operator/manager/xmpp_node/v3/logging from local tst environment

  5. scripts deploy_operator/manager/xmpp_node/v3/logging from tst prod environment

  6. rsync prod deploy scripts

  7. Use procedure below 'manual deployment' for instructions on individual projects.

phase 2:

  1. create dev environment (vhost) on tst server

  2. scripts deploy_operator/manager/xmpp_node/v3/logging from local dev environment

  3. add to deploy script:

    1. developer name

    2. timestamp

  4. run integration tests before deploy

  5. roll back possibility / zero downtime deployment

  6. add inline backup.tar.bz on server (see v2 deploy)

 

For each Major version a branch will be created, i.e. v0, v1.

(hopefully we can move towards Continues Integration and Deployment)

 

Manual deployment:

 

To update V3:

  1. ssh cobrowser_deploy@cbng0.tst.cobrowser.net (make sure your public key is on the server)

  2. cd /releases/CBNG0/

  3. copy these to the testing server with something like this:

    1. rsync -avz -e ssh --exclude-from /home/john/dev_partition/v3Exclude /home/john/dev_partition/v3/ cobrowser_deploy@cbngo.tst.cobrowser.net:/var/app/core/CBNG0

  4. clear the cache -> app/console cache:clear

  5. OPTIONAL: run php ./bin/createEnvironment.php

  6. logout

To update CB_manager:

  1. Compile application for deployment (you should be on master branch): where you normally run 'grunt serve', now run 'grunt serve:dist' and you should get (an updated) 'dist' folder in the root of the cb_manager project.

  2. Quickly check that this works locally, so we exclude minification issues.

  3. copy these to the testing server with something like this:

rsync -avz -e ssh --exclude-from /home/john/dev_partition/cbmExclude /home/john/dev_partition/cb_manager/dist/ cobrowser_deploy@cbngo.tst.cobrowser.net:/releases/cb_manager/

 

cbmExclude looks like this:

 

.git

.idea

config/config.js

atlassian-ide-plugin.xml

scripts/config/config.js

To update CB_Operator:

  1. Compile application for deployment (you should be on master branch): where you normally run 'grunt serve', now run 'grunt serve:dist' and you should get (an updated) 'dist' folder in the root of the cb_operator project.

  2. Quickly check that this works locally, so we exclude minification issues.

  3. copy these to the testing server with something like this:

rsync -avz -e ssh --exclude-from /home/john/dev_partition/cbmExclude /home/john/dev_partition/cb_manager/dist/ cobrowser_deploy@cbngo.tst.cobrowser.net:/releases/cb_operator/    

Comments

0 comments

Please sign in to leave a comment.