Created
May 17, 2022 13:36
-
-
Save AdamWorley/00d54d9321740b968ed9e21b66cf93e6 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name | ring | quadrant | isNew | description | |
|---|---|---|---|---|---|
| Azure DevOps | Adopt | Platforms | FALSE | <p>As the <strong><a href="https://azure.microsoft.com/en-us/services/devops/">Azure DevOps</a></strong> ecosystem keeps growing, our teams are using it more with success. These services contain a set of managed services, including hosted Git repos, build and deployment pipelines, automated testing tooling, backlog management tooling and artifact repository. We've seen our teams gaining experience in using this platform with good results, which means Azure DevOps is maturing. We particularly like its flexibility; it allows you to use the services you want even if they're from different providers. For instance, you could use an external Git repository while still using the Azure DevOps pipeline services. Our teams are especially excited about <a href="https://azure.microsoft.com/en-us/services/devops/pipelines/">Azure DevOps Pipelines</a>. As the ecosystem matures, we're seeing an uptick in onboarding teams that are already on the Azure stack as it easily integrates with the rest of the Microsoft world.</p> | |
| Azure Pipeline templates | Adopt | Platforms | FALSE | <p><strong><a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops">Azure Pipeline templates</a></strong> allow you to remove duplication in your Azure Pipeline definition through two mechanisms. With "includes" templates, you can reference a template such that it will expand inline like a parameterized C++ macro, allowing a simple way of factoring out common configuration across stages, jobs and steps. With "extends" templates, you can define an outer shell with common pipeline configuration, and with the <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass#required-template">required template approval</a>, you can fail the build if the pipeline doesn't extend certain templates, preventing malicious attacks against the pipeline configuration itself. Along with <a href="/radar/platforms/circleci">CircleCI</a> Orbs and the newer <a href="/radar/platforms/reusable-workflows-in-github-actions">GitHub Actions Reusable Workflows</a>, Azure Pipeline templates are part of the trend of creating modularity in pipeline design across multiple platforms, and several of our teams have been happy using them.</p> | |
| GitHub | Hold | Platforms | TRUE | <p><strong>GitHub</strong> is a widley used platform for managing and maintaining source code for projects. GitHub has functionality that can add extra benefits to projects as well, such as the ability to scan for vulnerabilities and automatically apply patches (when configured) removing the need to monitor for CVEs manually. GitHub has tools that allow for team and project management though these features are lacking when compare with Azure Devops. A benefit of moving to GitHub is the tighter integration with GitHub workflows that are billed by the minute instead of servers, this would allow us to run any number of pipelines in parallel improving the throughput of our merges. Unfortunately the pricing around GitHub means that it is prohibitive at the moment to migrate to, but we would like in the future.</p> | |
| GitHub Actions | Hold | Platforms | TRUE | <p><strong><a href="https://docs.github.com/en/actions">GitHub Actions</a></strong> has grown considerably last year. It has proven that it can take on more complex workflows and call other actions in composite actions among other things. It still has some shortcomings, though, such as its inability to re-trigger a single job of a workflow. Although the ecosystem in the <a href="https://github.com/marketplace?type=actions">GitHub Marketplace</a> has its obvious advantages, giving third-party GitHub Actions access to your build pipeline risks sharing secrets in insecure ways (we recommend following GitHub's advice on <a href="https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions">security hardening</a>). However, the convenience of creating your build workflow directly in GitHub next to your source code combined with the ability to run GitHub Actions locally using open-source tools such as <a href="https://github.com/nektos/act">act</a> is a compelling option that has facilitated setup and onboarding of our teams.</p> | |
| Lighthouse | Assess | Tools | TRUE | <p><strong><a href="https://developers.google.com/web/tools/lighthouse/">Lighthouse</a></strong> is a tool written by Google to assess web applications and web pages, collecting performance metrics and insights on good development practices. We've long advocated for <a href="/radar/techniques/performance-testing-as-a-first-class-citizen">performance testing as a first-class citizen</a>, and the additions to Lighthouse that we mentioned five years ago certainly helped with that. Our thinking around <a href="/radar/techniques/architectural-fitness-function">architectural fitness functions</a> created strong motivation for tools such as Lighthouse to be run in build pipelines. With the introduction of <a href="https://github.com/GoogleChrome/lighthouse-ci">Lighthouse CI</a>, it has become easier than ever to include Lighthouse in pipelines managed by <a href="https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#configure-your-ci-provider">various tools</a>.</p> | |
| Syft | Assess | Tools | TRUE | <p>One of the key elements of improving "supply chain security" is using a <a href="/radar/techniques/software-bill-of-materials">Software Bill of Materials (SBOM)</a>, which is why publishing an SBOM along with the software artifact is increasingly important. <strong><a href="https://github.com/anchore/syft">Syft</a></strong> is a CLI tool and Go library for generating an SBOM from container images and file systems. It can generate the SBOM output in multiple formats, including JSON, <a href="/radar/platforms/cyclonedx">CycloneDX</a> and SPDX. The SBOM output of Syft can be used by <a href="/radar/tools/grype">Grype</a> for vulnerability scanning. One way to publish the generated SBOM along with the image is to add it as an attestation using <a href="/radar/tools/cosign">Cosign</a>. This allows consumers of the image to verify the SBOM and to use it for further analysis.</p> | |
| Grype | Assess | Tools | TRUE | <p><strong><a href="https://github.com/anchore/grype">Grype</a></strong></a></strong> is a tool that can scan for and identify security vulnerabilities within an application or image. Grype can leverage the output from <strong>Syft</strong> and output a report with the results from the scan.</p> | |
| Volta | Trial | Tools | TRUE | <p>When working on multiple JavaScript codebases at the same time, it's often necessary to use different versions of Node and other JavaScript tools. On developer machines, these tools are usually installed in the user account or the machine itself, which means a solution is needed to switch between multiple installations. For Node itself there's nvm, but we want to highlight <strong><a href="https://volta.sh/">Volta</a></strong> as an alternative that we're seeing in use with our teams. Volta has several advantages over using nvm: it can manage other JavaScript tools such as Yarn; it also has the notion of pinning a version of the toolchain on a project basis, which means that developers can simply use the tools in a given code directory without having to worry about manually switching between tool versions — Volta simply uses shims in the path to select the pinned version. Written in Rust, Volta is fast and ships as a single binary without dependencies.</p> | |
| CDKTF | Hold | Tools | TRUE | <p>By now many organizations have created sprawling landscapes of services in the cloud. Of course, this is only possible when using <a href="/radar/techniques/infrastructure-as-code">infrastructure as code</a> and mature tooling. We still like <a href="/radar/tools/terraform">Terraform</a>, not the least because of its rich and growing ecosystem. However, the lack of abstractions in HCL, Terraform's default configuration language, effectively creates a glass ceiling. Using <a href="/radar/tools/terragrunt">Terragrunt</a> pushes that up a bit further, but more and more often our teams find themselves longing for the abstractions afforded by modern programming languages. <a href="https://www.terraform.io/cdktf"><strong>Cloud Development Kit for Terraform (CDKTF)</strong></a>, which resulted from a collaboration between AWS's <a href="/radar/platforms/aws-cloud-development-kit">CDK</a> team and Hashicorp, makes it possible for teams to use several programming languages, including TypeScript and Java, to define and provision infrastructure. With this approach it follows the lead of <a href="/radar/platforms/pulumi">Pulumi</a> while remaining in the Terraform ecosystem. We've had good experiences with CDKTF but have decided to keep it in the Assess ring until it moves out of beta.</p> | |
| Chrome Recorder panel | Assess | Tools | TRUE | <p><strong><a href="https://developer.chrome.com/docs/devtools/recorder/">Chrome Recorder panel</a></strong> is a preview feature in Google Chrome 97 that allows for simple record and playback of user journeys. While this definitely isn't a new idea, the way in which it is integrated into Chrome allows for quick creation, editing and running of scripts. The panel also integrates nicely with the performance panel, which makes getting repeated consistent feedback on page performance easier. While record/playback style testing always needs to be used with care in order to avoid brittle tests, we think this preview feature is worth assessing, especially if you're already using the Chrome Performance panel to measure your pages.</p> | |
| tfsec | Assess | Tools | TRUE | <p><strong><a href="https://github.com/aquasecurity/tfsec">tfsec</a></strong> uses static analysis of your terraform code to spot potential misconfigurations. tfsec can be enabled inside of CI/CD to provide regular reporting of any issues with terraform declarations. It has hundreds of rules to verify potential issues. There are also plugins available for <a href="https://marketplace.visualstudio.com/items?itemName=tfsec.tfsec">VSCode</a> and <a href="https://plugins.jetbrains.com/plugin/18687-tfsec-findings-explorer">JetBrains</a> that allow for a report to be generated locally.</p> | |
| npm workspaces | Assess | languages-and-frameworks | TRUE | <p>While many tools support multipackage development in the node.js world, npm 7 adds direct support with the addition of <strong><a href="https://docs.npmjs.com/cli/v8/using-npm/workspaces">npm workspaces</a></strong>. Managing related packages together facilitates development, allowing you, for example, to store multiple related libraries in a single repo. With npm workspaces, once you add a configuration in a top-level package.json file to refer to one or more nested package.json files, commands like <code>npm install</code> work across multiple packages, symlinking the dependent source packages into the root node_modules directory. Other npm commands are also now workspace aware, allowing you, for example, to execute <code>npm run</code> and <code>npm test</code> commands across multiple packages with a single command. Having that flexibility out of the box decreases the need for some teams to reach for another package manager.</p> | |
| Trunk Based Development | Adopt | Techniques | TRUE | <p>Trunk Based Development (TBD) is a version control management practice where developers merge small, frequent updates to a core “trunk†or main/master branch. Since it streamlines merging and integration phases, it helps achieve CI/CD and increases software delivery and organisational performance. The potential pitfalls of <strong>TBD</strong> are that it can become cumbersome around large PRs or long lived branches, however these two situations are best avoided in most branching strategies and so is not limited to TBD.</p> | |
| Kanban | Adopt | Techniques | TRUE | <p><strong>Kanban</strong> is a visual way to display work, it's a simple layout with work items displayed as <em>cards</em> within columns indicating the status of a work item. It is helpful to see the status of a team or project as you can easily see where the work is.</p> | |
| Stryker | Assess | Tools | TRUE | <p><strong><a href="https://stryker-mutator.io/">Stryker</a></strong> is used to 'Test you tests with mutation testing', this is to say that Stryker will modify tests to ensure that the assertions are stable. For example a test for 2+2=4 could be mutated to 2x2=4 (with only the operator switched) Stryker would identify that test as a mutant as it passed the test even after having been changed. This is useful to ensure that all of our test are of a high quality as test coverage alone does not indicate this.</p> | |
| MoneyHub | Assess | Platforms | TRUE | <p>We are looking into pulling in client banking details automatically from external sources, this is to allow us to have a better idea of how a client holds their money and how best we can make that money work for them. To enable this functionality we are looking to use <a href="https://www.moneyhub.com/">moneyhub</a> and their APIs to allow us to integrate this into myNetwealth.</p> | |
| DDD | Adopt | Techniques | FALSE | <p><strong>Domain-driven design</strong> (<strong>DDD</strong>) is a <a href="https://en.wikipedia.org/wiki/Software_design" title="Software design">software design</a> approach <a href="https://en.wikipedia.org/wiki/Domain-driven_design#cite_note-millet2015-1">[1]</a> focusing on modelling software to match a <a href="https://en.wikipedia.org/wiki/Domain_(software_engineering">domain</a> "Domain (software engineering)") according to input from that domain's experts.<a href="https://en.wikipedia.org/wiki/Domain-driven_design#cite_note-vernon2013-2">[2]</a></p> <p>In terms of <a href="https://en.wikipedia.org/wiki/Object-oriented_programming" title="Object-oriented programming">object-oriented programming</a> it means that the structure and language of software code (class names, <a href="https://en.wikipedia.org/wiki/Class_method" title="Class method">class methods</a>, <a href="https://en.wikipedia.org/wiki/Class_variable" title="Class variable">class variables</a>) should match the <a href="https://en.wikipedia.org/wiki/Business_domain" title="Business domain">business domain</a>. For example, if a software processes loan applications, it might have classes like LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.</p> | |
| Micro-Frontends | Adopt | languages-and-frameworks | TRUE | <p><strong>Micro-Frontends (MFEs)</strong> are way to compartmentalise the display and functionality of an interface into a standalone deployment that can be <em>injected</em> into a shell application. This provides the benefits of a smaller code base and well defined boundaries between systems as there is no immediate way for MFEs to interact leading to more loosely coupled systems. By being deployed independently there is no need to re-build an entire application when just a single area is changed. The drawbacks however are the complexity of developing an MFE and introducing them into a shell application, the tooling around this has improved so CLI commands can be used to perform most of the boiler plate and configuration.</p> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment