Skip to content

joachimdalen/azdevops-acceptance-criterias

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation


Logo

Acceptance Criterias

An extension to manage acceptance criterias
Explore the docs »

View Extension · Changelog · Report Bug · Request Feature

Azure DevOps builds Issues License
Visual Studio Marketplace Installs - Azure DevOps Extension Visual Studio Marketplace Last Updated Visual Studio Marketplace Rating

About The Project

Accepance Criterias is an extension to allow for better management of acceptance criterias in Azure DevOps.

work-hub-preview

Features

  • Several criteria types
    • Scenario based
    • Text based
    • Checklist based
  • Approval and rejection flows
  • Hub for processing criterias
  • Approval / Rejection comments
  • Processing history

On the roadmap

Getting Started

Prerequisites

  • A MarketPlace publisher Create a publisher

  • tfx-cli installed. Due to issues with outdated dependencies this is not included in package.json

    npm install -g tfx-cli
  • Pipelines uses the following extensions that needs to be installed in your organization in addition to default tasks:

Installation

  1. Clone the repo

    git clone https://github.com/joachimdalen/azdevops-acceptance-criterias.git
  2. Install dependencies

    > npm install
  3. Update publisher in vss-extension.dev.json

  4. Compile development version

    npm run prepare:dev
  5. Publish extension

  6. Share and install extension

  7. Run extension

    npm run serve:dev

    Note: You might need to open https://localhost:3000/ in your browser from time to time to accept the unsecure certificate to have the extension load properly from your local environment.

(back to top)

Usage

See documenation for rule usage.

(back to top)

Roadmap

See the open issues for a full list of proposed features.

(back to top)

Contributing

Contributions are welcome, both in the form of suggestions and code. Create

If you want to contribute code, I ask that you follow some guidelines.

  • New and changed features should to the best ability be covered by tests
  • Follow the branching policy:
    • feature/ for new features
    • bugfix/ for bug fixes
    • docs/ for documentation changes
  • If your change is related to an issue, use the id as the first part of the branch e.g bugfix/12-fix-crash-when-updating-rule
  • Pull requests should target the main branch
  1. Fork the Project
  2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
  3. Commit your Changes (git commit -m 'Add some AmazingFeature')
  4. Push to the Branch (git push origin feature/AmazingFeature)
  5. Open a Pull Request

(back to top)

Release and merge strategy

  • main is only deployed to PROD and tagged with v<extension_version>
    • Pull requests are always squash merged into main
    • main is the only branch where GitHub releases are created for
  • feature/* and bugfix/* are deployed to QA. For deployment to DEV using local assets (only manifest changes are deployed to dev), the Deploy to DEV instead of QA option needs to be checked when running the deployment pipeline.

QA and DEV are private development and verfication environments (publications of the extensions.) Submit a new issue if you for some reason wish access to either of these.

Note Access to these are not given for your local development. Please publish your own development release.

License

Distributed under the MIT License. See LICENSE for more information.

(back to top)

Contact

If you have generic questions about the project or usage you can make contact in the following ways:

(back to top)