Sean Trane Sciarrone

Migrating from SonarQube to SonarCloud

Tue, 22 Jan 2019 01:00:00 -0500

SonarCloud (SaaS) differs from SonarQube (self-hosted) in a number of different ways. This page documents the process of migrating from SonarQube to SonarCloud.

The most important thing to remember when performing this migration is that SonarCloud has different names for the configurable properties available in a sonar-project.properties file. The best place to find the property keys in SonarCloud is within the configuration settings area of the SonarCloud interface. Each configuration option therein shows the respective property key as would be used in the config file.

If a configuration option does not appear in the SonarCloud configuration settings, then it means it does not exist in SonarCloud. This is especially the case with SonarQube plugins, which do not exist in the same way on the cloud version, as SonarCloud comes with many popular plugins already baked into the service. SonarCloud does this because one cannot install plugins in SonarCloud, and this is a fundamental difference between the software. Not to worry though, because SonarCloud plugins are better integrated and easier to manage than it’s server-based counterpart.

Please use the sonar-project.properties standards and practices described on the SonarCloud Configuration page to make modifications to existing SonarQube project config files. Any SonarQube configuration properties that are not supported will simply be ignored by SonarCloud. When using SonarCloud, the sonar.organization config property is required or it will not upload - regardless of setting up the host URL and authentication properly.

When uploading results to SonarCloud or SonarQube, the sonar-scanner CLI usage is virtually the same, just a different host URL;

sonar-scanner -Dsonar.host.url=https://sonarcloud.io ...

Using SonarCloud with Travis CI

Travis CI has excellent integration with SonarCloud, requiring very little to get up and running. The first step is to ensure the Travis CI SonarCloud add-on is activated in the .travis.yml config file;

addons:
  sonarcloud:
    organization: sonar-org

Then you must ensure that the SonarCloud auth token is available as an environment variable; SONAR_TOKEN.

After that, you simply have to run sonar-scanner after your linting/testing is complete and, of course, that your sonar-project.properties file is configured properly and your test reports are consumable by Sonar.

script:
  - npm test
  - npm sonar-scanner

Using SonarCloud other CI tools/services

It is relatively painless to switch from SonarQube to SonarCloud, as it is simply a change from using a SonarQube server host to using sonarcloud.io. In addition to the hostname change, one must also provide authentication for SonarCloud.

To make this process easier for users and plans, environment variables be provided to be used within job scripting. Here are the variables to be provided:

`SONARCLOUD_HOST_URL`	`https://sonarcloud.io`
`SONARCLOUD_ORG`	`sonar-org`
`SONARCLOUD_TOKEN_PASSWORD`	`********`

Using SonarCloud with Bamboo

Bamboo Global Variables can be accessed using the ${bamboo_...} variable naming convention, for example; ${bamboo_SONARCLOUD_HOST_URL}. The following command is all that is needed;

sonar-scanner -Dsonar.host.url=${bamboo_SONARCLOUD_HOST_URL} -Dsonar.login=${bamboo_SONARCLOUD_TOKEN_PASSWORD}

Security Monitoring in GitHub

Wed, 16 Jan 2019 01:00:00 -0500

GitHub has data services that can scan a repository for known security vulnerabilities found in dependencies.

Settings and Configuration

Data Services

You can find configuration for GitHub Data Services on the Repository Settings page. It is advisable to enable all settings in this area. Security monitoring and alerting cannot happen unless GitHub is granted permission to scan the dependencies of a repository.

GitHub Alerts Settings

Vulnerability alerts can be sent to any person or team. You can find configuration options within the Alerts section of the Repository Settings page. The default is organization and repository admins. It is best practice to only add GitHub Teams, if necessary. Additionally, as the section description says; users can manage their own notification settings, which controls how alerts are sent/received.

GitHub Vulnerability Alerts

The primary location of a GitHub Vulnerability Alert is at the top of the Repository page, displayed only to individuals granted access via the Alerts Settings.

Clicking See security alert leads to the Alerts section of the Repository Insights page, which provides a summary of open vulnerabilities.

Clicking a vulnerability will lead to a Vulnerability Details page, where all additional information is available. The instructions provided are not necessarily advisable, as the may be signifying a “sub-dependency”, in which case the direct dependency would need the consideration.

Merging Strategies in GitHub

Tue, 15 Jan 2019 01:00:00 -0500

Different projects use different git merging strategies. Even though this post is really talking about git itself, you can use this information without actually using GitHub. It also applies to any other online Git frontends like Bitbucket as well.

TLDR: If you need to maintain all commit IDs in your branches after they are merged/deleted you must use Create a merge commit. If it’s an open source project with contributors, Squash and merge is the best choice. If it’s a private repo where you can control the engineers Rebase and merge is a good choice, however Squash and merge also works just as well.

Merge Options

The following dropdown is presented when the arrow to the right of the merge button is clicked:	Whichever one you select will automatically stay selected, so you don't have to select it each time.
Merge button options can be restricted on the Repository Settings page:

Merge Option Comparison

Each strategy has its own advantages and disadvantages. This table is worded in a way where a ✅ generally means it does that task/option/thing better. However, that’s not strictly true in all cases. In fact, you may specifically not want it to have that feature.

Topic	Create a Merge commit	Squash and merge
+ History is immutable The history is never modified, so commit IDs will always stay persistent. If your repository, build system, delivery pipeline, bundled application versions or documentation relies on commit IDs staying the same in your entire history (including deleted feature branches) then this can be a deal breaker that means you have to use Create a merge commit. It's important to note that rewriting history (if done correctly) should only affect the feature branches before they are merged into you main or stable branch. You would only rewrite history on the main branch if something went terribly wrong (such as passwords got accidentally committed and merged).	✅	⛔
+ Avoids introducing commits that break CI If you have a CI system running your tests (such as Travis CI), it will be likely be trigged when you push code. However, it does not test every commit, only the most recent. This means it's possible to push 5 commits where 4 of them cause a failure in the build system but the 5th one passes. A common scenario is when a build fails for a minor reason like a style check. People will push fixup commits like "fixing code style" or the dreaded "minor". Eventually the build will pass but all those broken commits will be merged in with the feature. If you need to rerun a build or use `git bisect` to locate when bugs were introduced (see Automatically locate when are where bugs were introduced with git bisect) you will have a hard time pinpointing errors that are real as opposed to unrelated failures. Also, unless you absolutely need to ensure commit IDs forever you will have a lot of patches that just aren't useful in your history.	⛔	✅
+ Keeps a linear commit history Branching in git is cheap, easy and wonderful. Even in mid-sized projects with a handful of developers using the Create a merge commit strategy can lead to a very convoluted history that's often impossible to follow. For example: Keeping a linear commit history requires that branches will have to be rebased or collapse their commits on top of the latest head of the branch they wish to merge into. This changes the history (and therefore commit IDs) of the branches, but it also provides a single line of history that is much easier to follow and understand.	⛔	✅
+ Is easier for git beginners Even though nothing is really deleted in git and you can always recover a bad rebase using the `git ref-log`. It can still be a real problem for beginners that get themselves into a situation that they haven't yet developed the git ninja skills to work their way out of. This is often why projects opt for simple merge commits. It's about as full proof as you can get in terms of preventing the engineer from getting into sticky situations.	✅	✅
+ Easily link back to the Pull Request This can be very important for open source projects where all of the issues and discussions are in GitHub itself. GitHub will automatically recognize issue and PR numbers in the form of "#123" in your commit messages and create real links back to those entities. Except for Rebase and merge, GitHub will include these automatically for you in the commit messages making it much nicer and easier when exploring the commit history to identify why things were changed.	✅	✅
+ Avoids "code cleanup" style commits Referencing back to Avoids introducing commits that break in CI, people that are not comfortable with rebasing will often create new commits to fix up the tests or builds. These are of no use in your history and actually make it harder to locate the real commit that made the genuine change to identify the motivation or description. This is where Squash and merge really shines and works great in open source projects where the experience of engineers will vary and all changes will be put together in a single commit with a link back to the issue and/or pull request.	⛔	✅
+ Merge conflicts are easier to deal with Rebasing (especially for those new to git) can sometimes be a more complicated way to deal with conflicts because you are dealing with lots of small conflicts that affect conflicts further down the line. We have all done it. When you realized halfway through a rebase that you have chosen the wrong side and you will be dealing with that same conflict many more times. If your project is dealing with external engineers or less experienced engineers it can be tough to enforce and make sure they have a nice rebase history.	✅	✅
+ Can edit the message at merge time Sometimes you want to edit the commit message when merging. To fix spelling mistakes, adding extra ticket numbers, etc. Squash and merge is great for this.	⛔	✅
+ Avoids suppressing tags Tags are just labels that point to specific commit IDs. When rebasing or squashing the history is modified and so the existing commits that were rebased will now have a different commit IDs. If you rebase your feature branch you will find that any tags you previously had will now be gone, because they point to commits that are no longer in the history of your branch. The tags are still valid and will not be removed but there is no way to move tags to the equivalent rebased commit, even if no patches or merge conflicts were encountered. Tags created on your main or stable branch will stay intact because rebasing and squashing will only append new commits, but any tags within the feature branch will disappear form that history.	✅	⛔

Using Travis CI

Mon, 22 Oct 2018 02:00:00 -0400

As a continuous integration platform, Travis CI supports your development process by automatically building and testing code changes, providing immediate feedback on the success of the change. Travis CI can also automate other parts of your development process by managing deployments and notifications.

Getting started with Travis CI

It’s easy to get started with Travis CI. Their documentation has a page describing it; Travis CI for Beginners. There is also a great Travis CI Tutorial. However, there are some important things to take note of:

You should sign into Travis CI using your GitHub login. This is because Travis CI will automatically show you repositories that you have read permissions to in GitHub, and it will restrict administrative control to those who also have admin permissions to a repo in GitHub.
Travis CI is free for public repositories. You can, and should, experiment and learn Travis using a public repo in your personal GitHub account. You can sandbox and break things without having any effect on business operations. Everyone should take advantage of this.
Travis CI is much more powerful, by a significant magnitude, than you are probably aware of. Do lot let perception control your reality. Travis CI can achieve the simplest of CI/CD plans with ease, but it is also capable of managing much more complex plans. Due to it’s excellent support for Docker, there really are few limits to what can be achieved.

Limitations of Travis CI

No tool is without limitations and negative aspects. It is important to note the following limitations of Travis CI, although continual improvements to the platform cause this list to shrink every year.

You cannot share build artifacts across jobs. It is important to note that jobs do not share storage, as each job runs in a fresh VM or container. If your jobs need to share files (e.g., using build artifacts from the “Test” stage for deployment in the subsequent “Deploy” stage), you need to use an external storage mechanism such as an image repository or a remote server.

Travis CI Configuration

Breaking down the Travis CI configuration file

This is a top-down examination of a typical Travis CI configuration file, .travis.yml, and a description of the best practices exhibited therein.

Configuration	Description
`sudo: required`	The ``sudo`` property is no longer required and its use is now discouraged. It had been ``false`` by default, and marking in as ``required`` was necessary when using Docker. However, ``required`` is now the default state and any other setting is deprecated. It is therefore no longer needed to have this line, but important to make note of it, as it can be found in many configuration examples.
`language: node_js`	The ``language`` property is the most typical method of selecting the image that will be used for builds. ``node_js`` is the most popular, not only because JavaScript is the most popular language but also because the image also contains other system dependencies, such as; Java, Ruby, etc. Making it ideal for most build requirements.
`node_js: - '8'`	If ``node_js`` is the selected language/image, then you can specify which Node version(s) using the ``node_js`` property. As depicted, this property supports an array of values. This is useful when required to test code against multiple versions of Node.
`cache: directories: - ~/.npm - node_modules npm: true`	The ``cache`` property is used to dictate which dependencies and/or directories should be cached across build jobs and stages. This is most helpful to avoid running dependency installations more than once, saving up to 2 minutes for each additional job.
`notifications: email: false`	The ``notifications`` property is used to configure build notification settings. To avoid an overabundance of emails, it is common to always include this option and ensure the subsequent ``email`` property is marked as ``false``.
`services: - docker`	The ``services`` property is used to activate services to be made available to build jobs. The most common of these services is ``docker`` and this should be enabled on all plans.
`addons: sonarcloud: organization: sonar-org-name`	The ``addons`` property is used to activate additional 3rd party applications and integrations. This is most commonly used for things like SonarCloud integration and Chrome support. As depicted here, every single Travis CI build plan should have ``sonarcloud`` as an add-on with your ``sonar-org-name`` as the ``organization``. The SonarCloud add-on is required to ensure the ``sonar-scanner`` binary is available and connected to the matching SonarCloud profile. Please note that the Travis CI plan must also provide the `SONAR_TOKEN` as an environment variable so that ``sonar-scanner`` can authenticate the account.
`git: depth: false`	The ``git`` property is used to control Git configuration. This is most commonly used to increase the default depth (50 commits) of GitHub pulls. When you want Travis CI to be able to analyze more than just the absolute latest commits to the master branch, you need increase this setting or disable it altogether. For example; if you want to automate your releases and changelogs, then you need to be able to analyze as many commits as are applicable to said release. In many cases, this can exceed the default. The more automation and contributors you have, the more this setting can interfere.
`branches: only: - master - /^greenkeeper.*$/`	The ``branches`` property is used to control which branches Travis CI will watch for commits. This should always include the primary development branch, i.e.; ``master``. Additional branches should be activated on a case-by-case basis. For example, if the repository is integrated with Greenkeeper, then you must add support for ``greenkeeper/...`` branches so they can be processed. Pull Requests are automatically processed if they are made against the branches listed in this configuration. In this example; any PR made against the ``master`` branch will be automatically processed. This means every PR will be able to exhibit accurate Status Checks in GitHub, capable of preventing PR's from being merged if they fail the CI plan.
`env: global: - PATH=$HOME/.local/bin:$PATH - PATH=$PWD:$PATH`	The ``env`` property is used to supply environment variables which, for most plans, should only be stored in the Travis CI Build Settings area - only accessible to repository admins. Travis CI supports encryption of environment variables, but it is still best practice to keep these things out of the config file. The primary value of the ``env`` property is modifying global variables, especially when needing to modify ``PATH`` variable. The example provided shows the best practice for ensuring globally installed packages are accessible at the command line, in addition to the current active directory (``PWD``).
`before_install: - npm install -g greenkeeper-lockfile`	The ``before_install`` property is generally used for installing global dependencies. It can be ignored but it is best practice to use it for any system-level provisioning, and using the ``install`` property for application-level installation and provisioning.
`install: - travis_retry npm install`	The ``install`` property is used to run all installation scripting, such as ``npm install``. The caveat here, as exhibited in the example, is that the command should always be prefixed with the ``travis_retry`` command - which will ensure that any erroneous install failures will be retried before failing the build. This can be common during dependency installations when things like network drop-offs and registry blips affect the reliability of a plan. Note: the ``travis_retry`` command can be used in front of any command to ensure that it is retried upon failure.
`stages: - test - name: deploy if: repo = profile/repo AND type != pull_request AND branch = master`	The ``stages`` property is used to segment jobs into individual stages. Whilst this is not a required property, it is best practice to ensure that subsequent jobs are not run if a previous job/stage has failed. This is because Travis CI will run all scripts within a job even if a failure occurs during the first script. The job would still fail, but not before all scripts run. This has a benefit of observing just how many scripts failed, instead of just the first one. But it has the unfortunate consequence of potentially running a script that should be run if previous failures occurred. This is obviously the case with things like deployments, but can also play a role in other areas, such as; ensuring a build doesn't run for 10 minutes if a failure occurred in the first 2 minutes. As Travis CI is priced based on concurrent builds, it is important to ensure you do not unnecessarily waste build time. As exhibited in the example, stages are a great way to add conditionals to restrict if and when a stage is run. The example shows how to restrict a deployment stage to just the master branch of the explicit repo and not on any PR's. Note: stages are processed in a linear fashion, meaning subsequent stages cannot run until a previous stage as completed successfully.
`jobs: include: - stage: test name: 'Checks and Tests' script: - npm run lint - npm run test - npm run build - stage: deploy name: 'Publish and Release' script: - npm run semantic-release`	The ``jobs`` property is used to group all scripts/command into individual jobs. When using stages, you can have multiple jobs within the same stage. The example show one job per stage, but there is plenty of documentation describing the alternative.

Conditional scripting and statements

Travis CI provides a number of methods for wrapping build stages and jobs with conditional statements. There is also a page describing the available conditions, and a page describing how conditionals can be tested. You can also find a list of environment variables that can be used in conditional statements.

There are plenty of standard methods to learn therein. But there is little documentation about inline conditionals and the quirks of their behavior. This is a list of those quirks;

Inline conditional statements should be enclosed in single-quotes or they will not be processed properly; '[[ $TRAVIS_BRANCH = master ]] && echo "is master" || echo "is not master";'
All statements should end with a semicolon to ensure the statement is closed properly.
Any unmet inline conditional will trigger a premature fail/exit of the build plan. This is because Travis CI expects all scripts output to complete without error. If a conditional fails, this does not occur. It is therefore required to provide an “else” branch in the conditional statement. However, the “else” must also not fail. So it is common to simply “echo” some text that signifies the bypass.

script:
  - '[[ $TRAVIS_BRANCH =~ ^greenkeeper.*$ ]] && greenkeeper-lockfile-update || echo "Skipping greenkeeper-lockfile-update";'
  - '[[ $TRAVIS_BRANCH =~ ^greenkeeper.*$ ]] && npm audit || echo "Skipping npm audit";'
  - commitlint-travis
  - npm run lint
  - npm run build
  - travis_retry github-label-sync -a "$GH_TOKEN" -l 'https://git.io/fAe5i' profile/repo
  - npm run test
  - '[[ $TRAVIS_BRANCH = master ]] && sonar-scanner || echo "Skipping sonar-scanner";'
  - '[[ $TRAVIS_BRANCH =~ ^greenkeeper.*$ ]] && greenkeeper-lockfile-upload || echo "Skipping greenkeeper-lockfile-upload";'

SonarCloud Configuration

Mon, 15 Oct 2018 02:00:00 -0400

Enhance your workflow with continuous code quality, SonarCloud automatically analyzes and decorates pull requests on GitHub, Bitbucket and Azure DevOps on major languages. This page and section describes the details of Sonar usage.

Sample Configuration for SonarCloud

sonar.organization=profile
sonar.projectKey=profile:sample-repo
sonar.projectName=Sample Repo
sonar.projectVersion=latest

sonar.links.homepage=https://github.com/profile/sample-repo#readme
sonar.links.ci=https://travis-ci.com/profile/sample-repo
sonar.links.scm=https://github.com/profile/sample-repo
sonar.links.issue=https://github.com/profile/sample-repo/issues

# sonar.analysis.mode=preview
sonar.exclusions=**/node_modules/**/*, **/__tests__/**/*, **/tests/**/*, **/spec/**/*, **/test.ts, **/*.test.ts, **/*.spec.ts, **/*.e2e.ts
# sonar.host.url=http://127.0.0.1:9000/sonar
# sonar.issuesReport.html.enable=true
# sonar.report.export.path=report.json
# sonar.scanner.dumpToFile = dumpFile.txt
# sonar.showProfiling = true
sonar.sourceEncoding=UTF-8
sonar.sources=src
sonar.tests=__tests__

# sonar.language=ts
sonar.typescript.tsconfigPath=tsconfig.json
sonar.typescript.lcov.reportPaths=coverage/lcov.info
sonar.typescript.tslint.reportPaths=coverage/unit-report.json

Sonar Modules Configuration

Sonar “Modules” are used to define individual packages, apps, etc. This is useful for the management of monorepo’s.

Each Sonar “Module” must have an identifier that can be used to override inherited properties. Module identifiers should use “snake_case” module names as shown in the examples below.

# Comma-separated list of Sonar "Module" identifiers:
sonar.modules=hello_world

# All Sonar configuration settings can be overridden using module identifier:
hello_world.sonar.projectName=Hello World
hello_world.sonar.projectBaseDir=packages/hello-world

Using Sonar Quality Gates

Tue, 18 Sep 2018 02:00:00 -0400

SonarQube and SonarCloud require the use of Quality Gates to ensure code quality is maintained. This page contains descriptions for the variety of recommended Quality Gates that we judge our software by.

The need for quality gate levels

There are several levels of achievement when judging high quality software. Each piece of software has a different lifespan, and software with a longer lifespan tends to lose quality over time as software becomes more challenging to maintain. You can have software that has changed hands, and while quality standards may not have been high in the past, you want to ensure much higher standards on newly developed code.

Sonar provides a number of metrics and operators to describe code quality, but one must implement their own Quality Gates to get effective use out of the functionality. The more opinionated the Quality Gates are, the more effective they can be at maintaining high code quality standards.

You want software engineers to be incentivized to achieve high quality standards, while being flexible enough to not block momentum. If Quality Gates are not used to prevent code changes of a lesser standard, they can easily become blockers if there isn’t a prescriptive and opinionated way to handle them and describe what they mean.

Sonar Quality Gates

Platinum Quality Gate

Only applications and codebases of the highest quality are capable of passing the Platinum Quality Gate.

Platinum apps and their developers demonstrate a true passion for excellence. They should be recognized and rewarded as the metrics required for platinum status are no small feat for developers to achieve. That is why so few apps will be capable of achieving platinum status.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	Yes	is greater than		0
Coverage	No	is less than	95%	90%
Coverage on New Code	Always	is less than		95%
Critical Issues	Yes	is greater than		0
Duplicated Lines (%)	No	is greater than	0%	1%
Duplicated Lines on New Code (%)	Always	is greater than		0%
Maintainability Rating	Never	is worse than		A
Maintainability Rating on New Code	Always	is worse than		A
Major Issues	No	is greater than	5	10
New Major Issues	Always	is greater than	0	5
Reliability Rating	Never	is worse than		A
Reliability Rating on New Code	Always	is worse than		A
Security Rating	Never	is worse than		A
Security Rating on New Code	Always	is worse than		A

Gold Quality Gate

The Gold level is reserved for the applications and codebases that take the next leap above the industry standard.

Developers of Gold apps are reaching for excellence and demonstrating a very high level of code quality. They have a very real opportunity to take the next step to excellence.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	Yes	is greater than		0
Coverage	No	is less than	90%	85%
Coverage on New Code	Always	is less than		90%
Critical Issues	Yes	is greater than		0
Duplicated Lines (%)	No	is greater than	0%	3%
Duplicated Lines on New Code (%)	Always	is greater than	0%	1%
Maintainability Rating	Never	is worse than		A
Maintainability Rating on New Code	Always	is worse than		A
Reliability Rating	Never	is worse than		A
Reliability Rating on New Code	Always	is worse than		A
Security Rating	Never	is worse than		A
Security Rating on New Code	Always	is worse than		A

Silver Quality Gate

Silver status represents the industry standard and should be the baseline that every application and codebase aim to achieve.

Most apps should fall into this category. When quality gates below this are applicable to more apps, there should be unrest. While it is acceptable for an app to remain indefinitely at Silver status, it is totally unacceptable for an app to remain at any lower level.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	Yes	is greater than		0
Coverage	No	is less than	85%	80%
Coverage on New Code	Always	is less than		85%
Critical Issues	No	is greater than	5	10
Duplicated Lines (%)	No	is greater than	1%	5%
Duplicated Lines on New Code (%)	Always	is greater than	0%	3%
Maintainability Rating	Never	is worse than	A	B
Maintainability Rating on New Code	Always	is worse than		A
New Critical Issues	Always	is greater than		0
Reliability Rating	Never	is worse than	A	B
Reliability Rating on New Code	Always	is worse than		A
Security Rating	Never	is worse than		A
Security Rating on New Code	Always	is worse than		A

Bronze Quality Gate

Applications and codebases achieving Bronze status are on the precipice of industry standard acceptability, but falling short in some key areas.

Developers of Bronze apps should not remain bronze for long, as the industry standard is well within reach and only complacence can keep them from it.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	Yes	is greater than		0
Coverage	No	is less than	80%	70%
Coverage on New Code	Always	is less than		80%
Critical Issues	No	is greater than	15	30
Duplicated Lines (%)	No	is greater than	5%	10%
Duplicated Lines on New Code (%)	Always	is greater than	0%	5%
Maintainability Rating	Never	is worse than	B	C
Maintainability Rating on New Code	Always	is worse than		A
New Critical Issues	Always	is greater than	1	5
Reliability Rating	Never	is worse than	B	C
Reliability Rating on New Code	Always	is worse than		A
Security Rating	Never	is worse than	A	B
Security Rating on New Code	Always	is worse than		A

Iron Quality Gate

The Iron level is for applications and codebases that have a concerning lack of code quality, but preventions of it getting any worse.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	No	is greater than	0	5
Coverage	No	is less than	70%	60%
Coverage on New Code	Always	is less than	80%	70%
Critical Issues	No	is greater than	20	40
Duplicated Lines (%)	No	is greater than	10%	20%
Duplicated Lines on New Code (%)	Always	is greater than	0%	10%
Maintainability Rating	Never	is worse than	B	C
Maintainability Rating on New Code	Always	is worse than	A	B
New Blocker Issues	Always	is greater than		0
New Critical Issues	Always	is greater than	1	10
Reliability Rating	Never	is worse than	B	C
Reliability Rating on New Code	Always	is worse than	A	B
Security Rating	Never	is worse than	A	B
Security Rating on New Code	Always	is worse than	A	B

Stone Quality Gate

Stone status is for applications and codebases that have a seriously alarming lack of code quality. The are preventions of it getting any worse, but the situation needs immediate attention.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	No	is greater than	0	10
Coverage	No	is less than	60%	50%
Coverage on New Code	Always	is less than	70%	60%
Critical Issues	No	is greater than	30	50
Duplicated Lines (%)	No	is greater than	20%	30%
Duplicated Lines on New Code (%)	Always	is greater than	10%	20%
Maintainability Rating	Never	is worse than	C	D
Maintainability Rating on New Code	Always	is worse than	B	C
New Blocker Issues	Always	is greater than	0	5
New Critical Issues	Always	is greater than	5	15
Reliability Rating	Never	is worse than	C	D
Reliability Rating on New Code	Always	is worse than	B	C
Security Rating	Never	is worse than	B	C
Security Rating on New Code	Always	is worse than	B	C

Wood Quality Gate

Software that is capable of spontaneous combustion at a second glance. The Wood status is no status at all really. The situation will either improve or be relegated to the bonfire of bad software.

Metric	On New Code	Operator	Warning	Error
Blocker Issues	No	is greater than	10	20
Coverage	No	is less than	50%	40%
Coverage on New Code	Always	is less than	60%	50%
Critical Issues	No	is greater than	40	60
Duplicated Lines (%)	No	is greater than	30%	40%
Duplicated Lines on New Code (%)	Always	is greater than	20%	30%
Maintainability Rating	Never	is worse than	C	D
Maintainability Rating on New Code	Always	is worse than	C	D
New Blocker Issues	Always	is greater than	0	10
New Critical Issues	Always	is greater than	10	20
Reliability Rating	Never	is worse than	C	D
Reliability Rating on New Code	Always	is worse than	C	D
Security Rating	Never	is worse than	C	D
Security Rating on New Code	Always	is worse than	C	D

GitHub Labels that are logical, colorful and sensible

Sat, 18 Aug 2018 02:00:00 -0400

The default GitHub Labels are, well… not ideal. This has been described many times:

There are many very good examples of GitHub Label strategies. Almost all of them are an improvement over the default. But for several reasons or another few, in practice, none of them have felt truly great or sustainable.

Principles

The presets were designed according to the following thoughts and principles:

GitHub Labels are used for both Issues and Pull Requests (PR), therefore the label context should be agnostic.
An Issue/PR without labels should not require labels to solicit attention, therefore the default state should be label-less.
Issue/PR labels should only provide important context; priority, effort and the state of solution and/or decision-making.
“High Priority”, sure, but “Low Priority” is a joke; go label-less instead.
Labels and their associated colors should have a logical connection that is intuitive at-a-glance.
Labels should be lowercase. It’s easier to type and less competitive with Label-names.
Prefixes matter. Labels get chaotic without them. The chosen are;
- effort = relative effort involved, fibonacci from 1 to 13
- priority = designate immediacy; now, 2day or soon
- state = describe decision; approved, blocked, inactive or pending
- type = describe type; bug, chore, discussion, docs, feature, fix, security, testing
- work = describe situation; chaotic, complex, complicated or obvious
The only labels without prefixes are; breaking, good first issue, greenkeeper, help and semantic-release

Label Groups

Standard	Effort	Priority	State	Type	Work
Standard labels commonly used in most repositories.	Describes the relative effort to complete an issue or pull request.	Priority labels, but focused on describing the immediacy of attention required.	Describes the decision state of the issue or pull request.	Describes the type of issue or pull request.	Describes the kind of work involved in resolving the issue, using the Cynefin framework.

How It Works

github-label-sync is used to synchronize your GitHub labels with as few destructive operations as possible - similar labels get renamed.
The label config is loaded via path or URL, or more specifically; the config file supplied by @seantrane/github-label-presets.
The github-label-sync -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO} command is run to have the label config applied to your profile/repo.
The command can be run anywhere and anytime, but it’s recommended during a CI plan. This will automatically keep your labels clean and synchronized with your chosen configuration - depending on how often your plan is run, of course.

Usage

Required: Generate a GitHub Access Token, provide it via GITHUB_ACCESS_TOKEN environment variable. If you cannot provide token as env-var, you may also pass it via CLI.

Install npm install -g github-label-sync
Dry-run github-label-sync -d -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}
Run github-label-sync -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}
optional: provide token via param; github-label-sync -a ${GITHUB_TOKEN} -l ...

CI/CD

You can use your CI/CD process to automate the periodic syncing of your repository labels. This can help persist order automatically.

Travis CI

Make sure GITHUB_ACCESS_TOKEN env-var is available.

before_install: npm install -g github-label-sync
script: github-label-sync -d -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}
deploy:
  provider: script
  script: github-label-sync -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}

Config your own…

You can provide your own labels.json via the [ -l, --lables ] argument.

AI System for Normal Conversation

Thu, 10 May 2018 02:00:00 -0400

Google Duplex: An AI System for Accomplishing Real-World Tasks Over the Phone

Failing badly at Microservices

Mon, 30 Apr 2018 02:00:00 -0400

This is a very funny presentation given by David Schmitz at Devoxx, originally published on 30th August 2017.

10 Tips for failing badly at Microservices by David Schmitz

Creating User Macros on Confluence

Thu, 01 Feb 2018 01:00:00 -0500

Here are some User Macros for Atlassian Confluence.

AUI Button

## Macro name: aui-button ## Macro title: AUI Button ## Macro description: Add a "default" call-to-action button. ## Macro has a body: N ## @param Title:title=Title|type=string|required=true ## @param URL:title=URL|type=string|required=true <a href="$paramURL"><button class="aui-button">$paramTitle</button></a>

## Macro name: aui-header-nav ## Macro title: AUI Header Nav ## Macro description: Add a nav-bar header. ## Macro has a body: Y ## Body processing: Rendered ## Output: Rendered ## ## Developed by: Sean Sciarrone ## Date created: 2018-02-01 ## Installed by: Sean Sciarrone ## @noparams <nav class="aui-header"> <ul class="aui-nav"> $body </ul> </nav>

AUI Nav List Item

## Macro name: aui-nav-list-item ## Macro title: AUI Nav List Item ## Macro description: Add a linked list item to nav. ## Macro has a body: N ## @param Title:title=Title|type=string|required=true ## @param URL:title=URL|type=string|required=true <li><a href="$paramURL">$paramTitle</a></li>