Agile 1.6.0

Welcome to the Agile app - created and maintained by Sascha Wildgrube.

Overview

Manage agile software projects and deployments

Features

Disclaimer

Agile is NOT an officially supported ServiceNow product.

Agile does NOT come with any kind of warranty. If you use it, you own it!

System Requirements

Installation

  1. Create an account on GitHub - if not done already.
  2. Create a personal access token for your GitHub account.
  3. Add credentials to access GitHub - use "Basic Auth".
  4. Fork the repository https://github.com/saschawildgrube/servicenow-devtools.
  5. Go to Studio and import the DevTools application from source control.
  6. Perform all installation steps for the DevTools application documented here: https://www.wildgrube.com/servicenow-devtools/ 
  7. Fork the repository https://github.com/saschawildgrube/servicenow-agile.
  8. Go to Studio and import the Agile application from source control.
  9. The InstallApp() function must be executed.
    Run the following script as a background script in scope x_snc_agile:
  10. x_snc_devtools.InstallApp("x_snc_agile");

Configuration

  1. Assign groups or users the x_snc_agile.agilist role.
  2. Create a backlog.
  3. Specify the definition of ready and the definition of done.
  4. If applicable, specify the lead developer and the lead tester.
  5. Define components and associate them to the backlog.

Development Process / Backlog Item States

Please add the affected application names as a tags to the story.

  1. Draft / Need more info: The requirement description is being worked on or more information is required to implement the backlog item.
  2. Ready: The author of the item claims the item contains enough information to start development. A developer should be assigned to the backlog item.
  3. In Development: A developer works or is asked to work on the implementation of the backlog item in the DEV environment.
  4. Done / Commited to repo: The developer has completed their work and committed their changes to the source code repository - which makes the backlog item part of a subsequent deployment to the TEST environment.
  5. In Test: The changes related to the backlog item has been deployed to the TEST environemnt and a tester is asked to test the result.
  6. Test Failed / Showstopper / Back to development: A backlog item has failed the test and must be considered as a showstopper - so the current version on the TEST environment MUST NOT be deplyoed to the PROD environment. The backlog item is sent back to a developer who is now asked to fix issues. It is important to disiguish this state from "In Development" because the current deployment on TEST should not be deployed to the PROD environment as long as there are showstoppers. If a test failed but the issues are not considered as showstoppers, the version can be deployed to PROD and the state should be set to "In Development" which indicates that they do not represent a reason to delay deployment to PROD but still need to be worked on.
  7. Test Passed / Ready for PROD: The test has been passed and the backlog item is ready for deployment on the PROD environment.
  8. Review on PROD: Deployment to PROD environment has been completed. A final check should be done before the backlog item is marked as "Completed".
  9. Completed: The backlog item is finally completed.
  10. Cancelled: The backlog item will not be implemented or worked on any further.

Deployment Process

The following deployment process - no matter if performed manually or automated - should be applied to deploy applications (components).

From DEV to TEST

  1. Login to the DEV instance.
  2. Navigate to Studio.
  3. Switch to the application.
  4. Verify that the DEV branch is active.
  5. Document all changes.
  6. Set verson in application settings.
  7. Run all ATF tests and Instance Scan checks.
  8. Navigate to "Studio" / "File" / "Settings" and click on the button "Baseline Version".
  9. "Commit Changes" to DEV branch.
  10. Select "Create Branch" and choose the branch name according to the application version (or an alternative naming schema - e.g. "YYYY-MM-DD_hhmm").
  11. Select "Switch Branch" and select the DEV branch.
  12. Login to the TEST instance.
  13. Navigate to Studio.
  14. Switch to the application.
  15. Select "Apply Remote Changes" (this is necessary to update the list of available tags).
  16. Select "Switch Branch" and select the corresponding version branch.
  17. Verify that the now current branch has changed to the just created branch.
  18. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  19. Mark backlog items associated to the application in "Done / Commited to repo" as "In Test".

To PROD (roll-forward / roll-back)

  1. DO NOT PROCEED TO ROLL-FORWARD if there are stories "In Test" or in "Test Failed / Showstopper / Back to development"!
  2. Login to the PROD instance.
  3. Navigate to Studio.
  4. Switch to the application.
  5. Select "Apply Remote Changes" (this is necessary to update the list of available branches).
  6. Select "Switch Branch".
  7. Choose the branch name that represents the version that should be deployed.
  8. If in doubt, stash changes and reapply them afterwards. However it SHOULD NOT be necessary.
  9. Verify that the now current branch has changed to the just selected branch.
  10. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  11. Mark backlog items associated to the application in "Ready for PROD" as "Review in PROD".

Reference

Configuration Options

Roles

UI Actions

License

Copyright 2022-2024 by Sascha Wildgrube

Licensed under the Apache License, Version 2.0 (the "License")

You may not use Agile except in compliance with the License.

You may obtain a copy of the License at: https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Release Notes

1.6.0 - 2024-02-05

  1. Added function BacklogItemManageOrder() to manage backlog item order recursively considering the required backlog items (and their dependencies likewise). It is now no longer possible to set the order of a backlog item below the order of a required backlog item. Circular dependencies are detected and ignored. Dependent backlog items are also considered - so the tree of dependencies is both walked up and down.
  2. Added feature descriptions to the manual.

1.5.0 - 2024-01-29

  1. DevTools 1.80.0 is now required because of RecordManageOrder() and HtmlRenderTree().
  2. Added new UI Action "New Required Backlog Item".
  3. Added new UI Action "Dependencies" to display the dependency tree of a backlog item.
  4. The definition of ready is now also displayed in the "Ready" state so that the description can be compared with the definition of ready.
  5. The backlog items that require the current backlog item are displayed on the backlog item form.
  6. Refactored AppInstall() to not use .update() directly.
  7. AppSetDefaults() now sets the logging verbosity to "info".
  8. Improved manual on process states.
  9. Consistent use of "showstopper" instead of "show stopper".

1.4.0 - 2023-10-07

  1. The Agile app has been fully tested with Vancouver.
  2. Tokyo is no longer actively supported.
  3. DevTools 1.71.0 is now required.
  4. Added the "Low Prio" UI action to send a backlog item to the end of the backlog.
  5. New backlog items ALWAYS start in state "Draft". When a new backlog item was created from the state specific list views (e.g. "In Test") the new item inherited the state from the list filter. This has been fixed.
  6. The fields "Hotfixed in PROD" and "Order" are now read-only once the backlog item is closed.

1.3.0 - 2023-09-07

  1. Backlog item number and state can no longer be edited in list views.
  2. Backlog items can now be marked as "Hotfixed in PROD" to indicate that a hotfix is already in place in production.
  3. In the backlog item list view, the referenced components are no longer cut off.
  4. The order can now be edited in the backlog item form.
  5. Added the "Prio 1" UI Action to set a backlog item to the top of the backlog.

1.2.0 - 2023-06-08

  1. Agile is now fully tested in Utah.
  2. DevTools 1.63.0 is now required.
  3. San Diego is no longer actively supported.
  4. Added the "Cancel" UI action to set the state of a backlog item to "cancelled".
  5. Initializing the backlog's default component on new backlog item now works properly.
  6. The backlog item's short description is now a mandatory field.
  7. Added the default DevOps user to the components list view.
  8. Added default component and owner to the backlog list view.
  9. Removed display value from the backlog item form view.
  10. Users with the x_snc_agile.agilist role were unable to add comments, edit the short description and description and assigned_to fields. This has been fixed.

1.1.0 - 2023-03-06

  1. Introduced Personas: Backlog items can now be associated with Personas.
  2. Backlog items can now turn into "Complete" state from "Done" - for tasks that do not require production deployment - such as documentation or exploration tasks.
  3. New backlog items are now added to the end (with the next highest order value) by default.
  4. Backlog items can now specify required other backlog items.
  5. Backlog item's display value now shows the number, the state and the short description.
  6. A backlog item's component, tester, developer and owner is now set if the values are missing - so the feature now also works if there are multiple backlogs.
  7. All user references in backlog items, components and backlogs now filter for the x_snc_agile.agilist role.
  8. Components now have a description field.
  9. Added menu module "New Item".
  10. Added menu module for items "In Draft" and refined the list for "In Development" and "In Test".

1.0.0 - 2023-02-08

First baselined version