This app is designed to run on a Release scoped dashboard.
An alternate release tracking board with the following differences from the Portfolio > Release Tracking board:
- Level 1 Portfolio Items (aka Features) are organized into the iteration that matches their Planned End Date (NOT iteration stories)
- If a Level 1 Portfolio Item does not have a Planned End Date, then it will show up in the Unscheduled column
- Names of the features are included on the cards
- Board is read only and cards cannot be dragged across projects or iterations
- Child Dependencies are defined as stories that belong to features that are not in the same project as their parent feature. No story predecessors or successors are shown in this app. These are shown as red.
- Peer Dependencies are defined as features that are manually set to have dependency relationshiops (predecessor/successor) with features on the board. These are shown as blue. (This set currently toggles with the child dependencies)
Dataset for this app is the following:
- All Features associated explicitly with the currently selected release within the current project scope. This association is determined by comparing the Release Name only (not Name + ReleaseStartDate + ReleaseEndDate);
- Any orphaned Stories or Defects explicitly associated with the currently selected release within the selected project scope. Note that this behavior is different from the current release tracking board in that it does not show Stories or Defects associated with iterations within the Release timebox.
- Any "dependent" (as defined above) stories in the workspace. If the "dependent" story is outside of the currently selected project scope, it will still be shown.
- Show Stories - this will show all orphaned stories associated with the release AND any "dependent" stories for Features in the current project scope associated with the selected release.
- Show Defects - this will show all orphaned defects associated with the release in the current project scope.
- Show Dependencies - this will show all "dependency" lines between stories and features that do not share the same project.
- Use count or points -
Users will be able to click on the dependency icon to see individual dependency relationships. Popovers will not work when dependency lines are drawn
If you've just downloaded this from github and you want to do development, you're going to need to have these installed:
- node.js
- grunt-cli
- grunt-init
Since you're getting this from github, we assume you have the command line version of git also installed. If not, go get git.
If you have those three installed, just type this in the root directory here to get set up to develop:
npm install
If you want to use the automatic deployment mechanism, be sure to use the makeauth task with grunt to create a local file that is used to connect to Rally. This resulting auth.json file should NOT be checked in.
- src/javascript: All the JS files saved here will be compiled into the target html file
- src/style: All of the stylesheets saved here will be compiled into the target html file
- test/fast: Fast jasmine tests go here. There should also be a helper file that is loaded first for creating mocks and doing other shortcuts (fastHelper.js) Tests should be in a file named -spec.js
- test/slow: Slow jasmine tests go here. There should also be a helper file that is loaded first for creating mocks and doing other shortcuts (slowHelper.js) Tests should be in a file named -spec.js
- templates: This is where templates that are used to create the production and debug html files live. The advantage of using these templates is that you can configure the behavior of the html around the JS.
- config.json: This file contains the configuration settings necessary to create the debug and production html files.
- package.json: This file lists the dependencies for grunt
- auth.json: This file should NOT be checked in. This file is needed for deploying and testing. You can use the makeauth task to create this or build it by hand in this' format: { "username":"you@company.com", "password":"secret", "server": "https://rally1.rallydev.com" }
Use grunt debug to create the debug html file. You only need to run this when you have added new files to the src directories.
Use grunt build to create the production html file. We still have to copy the html file to a panel to test.
Use grunt test-fast to run the Jasmine tests in the fast directory. Typically, the tests in the fast directory are more pure unit tests and do not need to connect to Rally.
Use grunt test-slow to run the Jasmine tests in the slow directory. Typically, the tests in the slow directory are more like integration tests in that they require connecting to Rally and interacting with data.
Use grunt deploy to build the deploy file and then install it into a new page/app in Rally. It will create the page on the Home tab and then add a custom html app to the page. The page will be named using the "name" key in the config.json file (with an asterisk prepended).
You can use the makeauth task to create this file OR construct it by hand. Caution: the makeauth task will delete this file.
The auth.json file must contain the following keys: { "username": "fred@fred.com", "password": "fredfredfred", "server": "https://us1.rallydev.com" }
(Use your username and password, of course.) NOTE: not sure why yet, but this task does not work against the demo environments. Also, .gitignore is configured so that this file does not get committed. Do not commit this file with a password in it!
When the first install is complete, the script will add the ObjectIDs of the page and panel to the auth.json file, so that it looks like this:
{ "username": "fred@fred.com", "password": "fredfredfred", "server": "https://us1.rallydev.com", "pageOid": "52339218186", "panelOid": 52339218188 }
On subsequent installs, the script will write to this same page/app. Remove the pageOid and panelOid lines to install in a new place. CAUTION: Currently, error checking is not enabled, so it will fail silently.
Run this to watch files (js and css). When a file is saved, the task will automatically build, run fast tests, and deploy as shown in the deploy section above.
This task will create an auth.json file in the proper format for you. Be careful this will delete any existing auth.json file. See grunt deploy to see the contents and use of this file.
Get a full listing of available targets.