Package: augurlib
# Augur Developer MetricsHelp team leads, managers and developers track progress, improvement,gaps by combing data from multiple tools into an easy to use dashboardusing the Augur Development Method.This is a library that can be easily included into any client that wants tocollect data using ADM.# Augur InstallationTo install, you can do one of the following:## Install on command linepip install augurWithout changing your global index, this will install augur using the custom index this once.## Install in requirements.txtThen include augur as you would any other package:augur==<version>oraugur# Augur DevelopmentTo upload a new version of augur, you can modify your .pypirc file with the following:[dist-utils].... # whatever indexes you already had in therelocal...[local]repository: https://artifacts.ua-ecm.com/artifactory/api/pypi/ua-pypiusername: <username> # must have publish rightspassword: <password>You can use fabric to build and publish.>> pip install -g fabric>> cd /path/to/augur>> fab publish:bump_version_type=<major,minor or patch>,upload=<True,False>,update_in_vcs=<True,False>fab publish can perform all aspects of deployment optionally.  By default, it will only builda new package.  But you can also have it automatically bump the version (major,minor or patch),publish the new build to whatever artifact repo you've configured in .pypirc and automicallycommit and push the changes to git.## TestingTo run the very few tests that exist, create a file called fixtures.local.json in thetests/fixtures directory that looks like this:```json{"connections": {"jira": {"server": "https://<test_server>.atlassian.net/","username": "<atlassian_login_email>","password": "<atlassian_login_password>"},"db": {"type": "sqlite","sqlite": {"path": "<path_to_augur_src>/augur/tests/fixtures/db.sqlite"}}},"context": {"group": 1},"jira_test_data": {"jql": {"created_last_three_days":"created > startOfDay(-3d)"}}}```From the augur root source directory, run```bashpython -m tests.test_objects```# Augur Integration## SettingsIn order to use Augur there are some settings that it expects to be accessiblevia environment variables.  In some cases, there are defaults that are applied,in other cases, the initialization will fail if not specified.| Environment Variable |  Purpose                                 |   Default   | Example                        || -------------------- |:-----------------------------------------|:----------: |--------------------------------|| JIRA_INSTANCE        | The full url to the JIRA instance to use | Required    | http://voltron.atlassian.net/   || JIRA_USERNAME        | The full url to the JIRA instance to use | Required    | A username   || JIRA_PASSWORD        | The full url to the JIRA instance to use | Required    | It's a password   || JIRA_API_PATH        | The relative path to the root of the rest endpoints | rest/api/2 | rest/api/2  || CONFLUENCE_INSTANCE  | The full url to the Confluence instance  | JIRA_INSTANCE    | http://voltron.atlassian.net/wiki   || CONFLUENCE_USERNAME  | The full url to the Confluence instance  | JIRA_USERNAME    | A username   || CONFLUENCE_PASSWORD  | The full url to the Confluence instance  | JIRA_PASSWORD    | Another password   || GITHUB_BASE_URL  | The full url to the Github instance  | Required    | http://github.com/ || GITHUB_LOGIN_TOKEN  | The token of the user that should be used to access the API for the instance of github specificed in GITHUB_BASE_URL | Required    | cbab75c171843afef555d9dcbc212e0b54681b32 || GITHUB_CLIENT_ID | The client ID that has been registered for the client that is using this instance of the Augur library | Required    | e3d808650b4f45f9ac03 || GITHUB_CLIENT_SECRET | The client secret that has been registered for the client that is using this instance of the Augur library | Required    | f3d80e650b4d45f9ad15 |# Integration with External Tools## GithubThere is no explicit requirements for Github setup other than this: Augur was developed from the enterprise editionwhich means it's more acceptable for Github Organizations to be part of the hierarchy of the codebase.## Jira### Development ###A customized version of a python client is being used to retrieve Jira data via the REST API.  You'll notice that therequirements.txt file is pulling from our private pypi.  The code for this customized version is found here:https://github.ua.com/kshehadeh/jiraFor development locally, you can either get a clone of that repo then install it into your python environment:> cd /my/dev/folder> git clone git@github.ua.com:kshehadeh/jira.git> pip install -e /my/dev/folder/jiraor you can download directly from the private pypi like so:> pip install jira -i https://pypi-reader:ThOgrAVultiA@artifacts.ua-ecm.com/artifactory/api/pypi/ua-pypi/simpleThat user has read only access to the pypi repo only.### Groups, Workflows and TeamsAugur now supports creation of custom workflows.  To do this, a taxonomy ofwas created to organize them.* Groups* Workflow* Projects* Teams* Staff* Vendors#### GroupsA group in Augur is a group of people within an organization that share a commonworkflow.  For example, developers might use a workflow that is different thanthat used by the marketing team.  Groups are described by a single workflow anda set of teams.#### WorkflowsWhile Augur workflows are closely tied to Jira workflows there's not a 1:1 comparison.A workflow is made up of:* Statuses - The various statuses that this workflow includes* Resolutions - fixed, completed, etc.* Projects - the Jira projects that are considered part of the workflow* Project Categories - A jira project category that should be included in this project* Issue Types - The types of issues that should be considered identified selected when making queries* Defect Projects - Which projects within the list of projects above are used for storing defects##### StatusesWithin a workflow, statuses can be of three types (open, in progress, resolved).  This helpsus understand what tickets are actively being worked on for metrics purposes.##### ResolutionsWhen a ticket status is set to a resolved state, we look at the resolution types to understandthe success or failure of that issue.  So each resolution type supported has a typeas well: postive or negative.  So a positived resolution would be "fixed" and a negative onewould be "won't fix"##### ProjectsWe can indicate which projects to include by either specifying the project keys individuallyor using JIRA's project categories which is a more easy to manage because you simply haveto set the category of a project in JIRA and it will automatically be included in this workflow.##### Issue TypesWe can also indicate which issue types we should pay attention to.  This is helpful whenprojects have issue types that are used for tracking information that has nothingto do with the workflow - like individual todo items, etc.##### Defect ProjectsFinally, defect projects are projects that we specifically call out for consistingentirely of bugs found in production.  We can use this information to collect defectmetrics over time.  A defect project is not necessarily just all tickets in the projectbut can also be further filtered by the issue type.#### TeamsTeams are made up of staff who have a long list of attributes associated with each.We keep information about the staff such as who they work for, email, usernamesfor different tools, etc.##### SprintsSprints are not stored in the augur db explicitly but the agile board ID is usedto retrieve sprint information.  To ensure that the correct sprints are being read,sprint names must follow a certain format:<sprint_num> - Team <team_name>Example:001 - Team VoltronThis is to ensure that only sprints that are associated with the team areincluded in the metrics.  Due to the way Jira works, it is possible for asprint that is part of a different agile board to be included in the metricsif this formatting restriction is not used.##### NotificationsThe Augur database supports notification settings for individual staff members.Staff can customize notifications by channel and by content.  For example, we can turn off email or slack messagesfor build notification but we can also specify what type of build notifications we want to get.In the `notifications` table there are these fields:* build - Can be one or more of [slack,email] separated by commas* deploy - Can be one or more of [slack,email] separated by commas* build_types - Can be one or more of [all,upstream,myteam,otherteams] separated by commas*Build Types Explained*All - If all is in there, then everything else is ignored and all build types are sentupstream - This means that notifications for builds that occur in a non-team org and are the master branch will be sentmyteam - This means that notification for builds that occur in the committers own team org will be sentotherteams - This means that notifications for builds that occur in team orgs other than the committers will be sent.