Agile 1.8.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.

Backlog Item States

  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: Developers work on the implementation of the backlog item in the DEV environment.
  4. Done / Commited to repo: Developers have completed their work and committed their changes to the source code repository - which makes the backlog item available to be part of one or more baselined application versions.
  5. Basedlined: The team has baselined all related applications that were affected by the changes made for this backlog item - which enables the backlog item to be part of a subsequent deployment to the TEST environment.
  6. 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.
  7. 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 distinguish 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.
  8. Baselined Showstopper: A fix has been provided to resolve the showstopper. All relevant application versions have been baselined and are now ready for deployment to TEST.
  9. Test Passed / Ready for PROD: The test has been passed and the backlog item is ready for deployment on the PROD environment.
  10. Review on PROD: Deployment to PROD environment has been completed. A final check should be done before the backlog item is marked as "Completed".
  11. Completed: The backlog item is finally completed.
  12. 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).

Baseline an Application Version

  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 in the release notes section of the manual.
  6. Set verson in application settings.
  7. Run all ATF tests.
  8. Run (CodeSanity) Instance Scan checks.
  9. "Commit Changes" to the "dev" branch.
  10. Navigate to "Studio" / "File" / "Settings" and click on the button "Baseline Version".
  11. Login to the TEST instance.
  12. Navigate to Studio.
  13. Switch to the application.
  14. Select "Apply Remote Changes" (this is necessary to update the list of available tags).
  15. Select "Switch Branch" and select the corresponding version branch.
  16. Verify that the now current branch has changed to the just created branch.
  17. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  18. Mark backlog items associated to the application in "Done / Commited to repo" as "Baselined".

Deploy to TEST

  1. Login to the TEST instance.
  2. Navigate to Studio.
  3. Switch to the application.
  4. Select "Apply Remote Changes" (this is necessary to update the list of available tags).
  5. Select "Switch Branch" and select the corresponding version branch.
  6. Verify that the now current branch has changed to the just created branch.
  7. Run (CodeSanity) Instance Scan checks.
  8. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  9. Run all ATF tests.
  10. Mark backlog items associated to the application in "Baselined" as "In Test".

Deploy to PROD

  1. DO NOT PROCEED TO ROLL-FORWARD if there are backlog items "In Test" or in "Test Failed / Showstopper / Back to development" or "Baselined Showstopper"!
  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.8.0 - 2024-03-31

  1. DevTools 1.84.0 is now required.
  2. Introduced the "Baselined" and "Baselined Showstopper" states.
  3. Added menu item "Baselining" to list all backlog items that are "Done", "Baselined" or "Baseoined Showstopper".
  4. Backlog items that are "hotfixed in PROD" are marked in blue.

1.7.0 - 2024-02-05

  1. Utah is no longer actively supported.
  2. Agile has been fully tested with Washington.
  3. The backlog item dependency view "Work Plan" tab now hides already completed backlog items and does no longer show duplicates. This turns the view into a visualization of the remaining work to be done.
  4. If there is no developer, tester or owner assigned to a backlog item, the "Assigned To" field is cleared when entering the corresponding states.
  5. Fixed a defect in GetBacklogItemDependencies() which led to false-positive warnings on circular dependencies.
  6. Fixed a defect in BacklogItemManageOrder() which led incorrect ordering if multiple backlog items depend on the same backlog item which also has its own dependencies.

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