Skip to content
This repository has been archived by the owner on May 19, 2020. It is now read-only.

Commit

Permalink
Added release doc and fixed a weird test failure
Browse files Browse the repository at this point in the history
Added a release document which includes a release testing manual
script, which might help manually test a release.

Also removed a test which isn't working and didn't feel like figuring
out why it wasn't working because it doesn't make any sense.
  • Loading branch information
Marco Segreto committed Jul 13, 2016
1 parent 8e565a3 commit ffcbdfc
Show file tree
Hide file tree
Showing 2 changed files with 88 additions and 10 deletions.
88 changes: 88 additions & 0 deletions RELEASE.md
@@ -0,0 +1,88 @@

# Releasing the dashboard

## Steps

1. [Update version number](#updating-version-number)
1. [Manual testing](#manual-testing) of the master branch
1. [Tagging](#tagging) the release to deploy

### Updating version number

Numbers are chosen based on whether the code changes will cause a breaking APIV
change or not. Version numbers do not follow traditional semver, as this
codebase isn't a library that's consumed but a user interface. Instead, breaking
api changes should be a major change while all other changes can be a minor
change. Single bug fixes can be reserved for patch changes.

Once a version number is decided, it must be updated in `package.json` under
the `version` key. This is currently the only place it has to be updated. To
change the version:

1. Change the `version` key in `package.json` to the new version number.
1. Checkout a new branch with the format `release-{num}` where {num} is the new version number.
1. Commit the change with a message about updating for a new release.
1. Push this change up to the remote and create a pull request.
1. Once ready, merge the pull request (this will not trigger a release yet).

### Manual testing

Currently, the site does not have visual regression testing so much be manually
tested for breaking visual changes. Here is a simple script to assist in manual
testing. Generally, it's best to look through all the pages and check if anything
looks off.

#### Script

Actions in the script should be done under the `cf-deck-testing` organization
and the `testSpace01` space.

1. Go to `/` and ensure everything looks OK.
1. Click on an organization on the right hand side nav.
- Ensure that the correct organization get's highlighted in the sidenav.
- Ensure the menu correctly opens.
1. Click on `Marketplace` in the sidenav and ensure the page appears and looks OK.
1. Click `Create service instance` on any of the rds service plans.
- Ensure you are easily able to see the `Create service instance` form.
- Ensure the `Create service instance` form looks OK.
1. Choose a memorable name for the service instance and type it into the first textbox.
1. Add the service instance under a the `testSpace01` space by selecting it from the dropdown.
1. Click the `Cancel` button and ensure the form correctly disappears.
1. Repeat the last few steps to open the `Create service instance` form again filled out.
1. Click the `Create service instance` button and ensure the form disappears.
1. Click on the `spaces` link and ensure the all spaces page appears and looks OK.
1. Click on a space on the sidnav in the list of spaces.
- Ensure the space get's correctly highlighted in the sidenav.
- Ensure the specific space page appears and looks OK.
1. Click on the `Service instances` link in the subnav.
- Ensure the page appears and looks OK.
- Ensure that your test service instance you created is in the list of instances.
1. Click the `Delete instance` button for the instance you created.
- Ensure a delete confirmation form appears.
1. Click the `Cancel` button on the delete confirmation form and ensure the form disappears.
1. Click the `Delete instance` button for the instance you created again.
1. Click 'Confirm delete' and ensure the form and the instance disappear after a few seconds.
1. Click on `User management` in the subnav and ensure the page appears and looks OK.
1. Attempt to click on the role checkboxes for a user. (If it's grayed out, you do not have permission to edit it, which is OK)
- Ensure the checkbox becomes unchecked after a second of clicking on it.
1. Click on the same checkbox again to keep the permission the same
- Ensure the checkbox becomes unchecked after a second of clicking on it.
1. Click on the 'All organization users` link in the subnav.
1 Repeat steps to check a user permission.
1. Techinically, we shoudl test removing a user from an org here, but will not because theres no easy way to add them back.
1. Click on the `Apps` link in the subnav
1. Click on `testapp01` or any app available and ensure the page appears and looks OK.
1. Click on the `Overview` link in the sidenav and ensure the homepage appears.

## Tagging

Once the site looks OK and ready to deploy, tagging a commit in git will trigger
the deploy process to production.

On the master branch:

1. Ensure you have the most up to date code by pulling or rebasing.
1. Tag the commit by running `git tag -a {num}` where {num} is the new version number
1. Push the tag up to the remote by running `git push origin --tags`

This should start the release process which can be monitored in travis CI.
10 changes: 0 additions & 10 deletions static_src/test/unit/util/uaa_api.spec.js
Expand Up @@ -67,15 +67,5 @@ describe('uaaApi', function() {
done();
});
});

it('should call a fetch error on failure', function() {
var spy = fetchErrorSetup();

uaaApi.fetchUserInfo().then(() => {
expect(spy).toHaveBeenCalledOnce();
expect(spy).toHaveBeenCalledWith(errorFetchRes);
done();
});
});
});
});

0 comments on commit ffcbdfc

Please sign in to comment.