docs: fix internal links
This commit is contained in:
Stefan Rotsch
committed by
Stefan Rotsch
Stefan Rotsch
parent
014cc8d360
commit
84d5939770
@@ -6,7 +6,7 @@ tags: [devops]
|
||||
---
|
||||
|
||||
DevOps is a term that has been around for some years now.
|
||||
We understand DevOps as a philosophy and culture with related practices and tools - all with the aim of bringing (IT) Operations closer to Development.
|
||||
We understand DevOps as a philosophy and culture with related practices and tools - all with the aim of bringing (IT) Operations closer to Development.
|
||||
|
||||
Jez Humble described the devops movement like this: "a cross-functional community of practice dedicated to the study of building, evolving and operating rapidly changing, secure, resilient systems at scale".
|
||||
|
||||
@@ -32,7 +32,7 @@ As always, we are establishing "community of interests" to improve and promote t
|
||||
|
||||
Another important aspect and also enabler of DevOps practices is the increase of certain tool and methods - some of them are also represented in the Tech Radar. For example: Puppet Environments; Docker; Cloud Services, Terraform, Consul etc.
|
||||
|
||||
**DevSetup = Prod Setup, [Infrastructure as a Code](methods-and-patterns/infrastructure-as-code.html)**
|
||||
**Dev Setup = Prod Setup, [Infrastructure as a Code](/methods-and-patterns/infrastructure-as-code/)**
|
||||
|
||||
Keeping the development infrastructure setup close to production is also a commonly implemented practice and a direct result of the "Infrastructure as Code" method.
|
||||
Handling infrastructure and the required changes and innovations in ways similar to those used for applications is important; you can ready more about this here: Infrastructure as Code
|
||||
|
||||
@@ -7,7 +7,7 @@ tags: [devops]
|
||||
|
||||
The [ELK Stack](https://www.elastic.co/de/elastic-stack) is a powerful trio of tools that work together to provide a comprehensive solution for logging, searching, visualizing, and analyzing data in real time:
|
||||
|
||||
- **[Elasticsearch](../platforms-and-aoe-services/elasticsearch.html)**: A search and analytics engine that indexes and stores data.
|
||||
- **[Elasticsearch](/platforms-and-aoe-services/elasticsearch/)**: A search and analytics engine that indexes and stores data.
|
||||
- **Logstash**: A data processing pipeline that ingests and transforms various data formats.
|
||||
- **Kibana**: A visualization tool that creates interactive dashboards and reports.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: tools
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
Archiving indexed log data with a system like [Elasticsearch](../platforms-and-aoe-services/elasticsearch.html) can be expensive, and archiving it as simple text files makes it hard to query. [Loki](https://grafana.com/oss/loki/) solves this issue by adding a reference database based on [Kubernetes](../platforms-and-aoe-services/kubernetes.html) labels to each log line, similar to [Prometheus](../platforms-and-aoe-services/prometheus.html), but storing the log data inside a simple blob storage like AWS S3. This allows the user to query the data by predefined labels and keeps the costs for indexing low.
|
||||
Archiving indexed log data with a system like [Elasticsearch](/platforms-and-aoe-services/elasticsearch/) can be expensive, and archiving it as simple text files makes it hard to query. [Loki](https://grafana.com/oss/loki/) solves this issue by adding a reference database based on [Kubernetes](/platforms-and-aoe-services/kubernetes/) labels to each log line, similar to [Prometheus](/platforms-and-aoe-services/prometheus/), but storing the log data inside a simple blob storage like AWS S3. This allows the user to query the data by predefined labels and keeps the costs for indexing low.
|
||||
|
||||
Another benefit is that Loki does not have an endpoint for mutating log data, making the data immutable from a potentially compromised system.
|
||||
|
||||
|
||||
@@ -8,4 +8,4 @@ tags: [architecture]
|
||||
The Micro Frontends approach continues to prove to be a valuable pattern for large-scale systems developed by several teams.
|
||||
Therefore, we moved this pattern to "adopt".
|
||||
|
||||
We use [page composing](methods-and-patterns/page-composing.html) as one implementation of this pattern.
|
||||
We use [page composing](/methods-and-patterns/page-composing/) as one implementation of this pattern.
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [architecture]
|
||||
---
|
||||
|
||||
Page composing is a way to aggregate multiple independent page fragments into one combined web page.
|
||||
As an implementation of [Micro Frontends](methods-and-patterns/microfrontends.html), this approach supports to deploy and run services agnostic to the technologies used per team.
|
||||
As an implementation of [Micro Frontends](/methods-and-patterns/microfrontends/), this approach supports to deploy and run services agnostic to the technologies used per team.
|
||||
|
||||
The concept builds upon the fact that all involved services deliver valid HTML as their output.
|
||||
Our solution is a small application which takes care of gathering the page fragments from all services and composing each into a defined HTML template.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: methods-and-patterns
|
||||
tags: [agile, coding]
|
||||
---
|
||||
|
||||
While practicing [pair working](../methods-and-patterns/pair-working.html) for several years now at AOE, we began to explore [remote mob programming](https://www.remotemobprogramming.org/) extensively when we switched to remote working during the COVID-19 pandemic.
|
||||
While practicing [pair working](/methods-and-patterns/pair-working/) for several years now at AOE, we began to explore [remote mob programming](https://www.remotemobprogramming.org/) extensively when we switched to remote working during the COVID-19 pandemic.
|
||||
|
||||
Mob programming brings the driver/navigator pattern to another level by bringing a group of navigators into the game. With the entire development team focused on a single topic, a lot of common understanding and shared knowledge are generated during each session as everyone is involved in the development process. The result is less controversial code reviews (which might even be completely omitted) and the evolution of a team coding style in favor of individual ways of problem-solving.
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We have observed a decrease in our usage of Ansible recently. Our current focus lies more on immutable infrastructure using cloud providers. Nonetheless, Ansible still offers great benefits for mutable infrastructure that require support and is an excellent tool for achieving [Infrastructure as Code](../platforms-and-aoe-services/infrastructure-as-code.html) in such cases.
|
||||
We have observed a decrease in our usage of Ansible recently. Our current focus lies more on immutable infrastructure using cloud providers. Nonetheless, Ansible still offers great benefits for mutable infrastructure that require support and is an excellent tool for achieving [Infrastructure as Code](/platforms-and-aoe-services/infrastructure-as-code/) in such cases.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
We've previously used [AWS Fargate](../platforms-and-aoe-services/aws_fargate.html) when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When dealing with Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we decided on [Azure Container Instances](https://azure.microsoft.com/products/container-instances), as they appeared to align most closely with AWS Fargate in terms of simplicity.
|
||||
We've previously used [AWS Fargate](/platforms-and-aoe-services/aws_fargate/) when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When dealing with Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we decided on [Azure Container Instances](https://azure.microsoft.com/products/container-instances), as they appeared to align most closely with AWS Fargate in terms of simplicity.
|
||||
|
||||
However, while it's easy to get a container up and running with Azure Container Instances, it seems that this service is still in its early stages of maturity. Some notable limitations include the inability to automatically register containers in internal networks with Azure Application Gateway, a lack of support for internal DNS, occasional issues where containers need to be deleted and recreated instead of being smoothly replaced, and unexpected container restarts during the night without clear prior announcements or post-incident explanations.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: methods-and-patterns
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Since the release of React 18, many CSS-in-JS libraries like styled-components, emotion, and stitches have encountered a significant challenge. They generate CSS only at runtime, making them incompatible with streaming and [React Server Components](../methods-and-patterns/react-server-components.html). React developers have addressed this issue in an [article](https://github.com/reactwg/react-18/discussions/110), where they explicitly advise against using CSS-in-JS libraries that generate CSS at runtime.
|
||||
Since the release of React 18, many CSS-in-JS libraries like styled-components, emotion, and stitches have encountered a significant challenge. They generate CSS only at runtime, making them incompatible with streaming and [React Server Components](/methods-and-patterns/react-server-components/). React developers have addressed this issue in an [article](https://github.com/reactwg/react-18/discussions/110), where they explicitly advise against using CSS-in-JS libraries that generate CSS at runtime.
|
||||
|
||||
This has created substantial uncertainty among developers and the communities of these affected libraries. The question arises: Is it possible to refactor these runtime libraries into buildtime libraries? To date, none of the libraries have announced any such plans, and, unfortunately, one of the most popular new libraries, stitches, is [no longer being maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090).
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We've faded out Kubernetes Operators as a standalone recommendation because they are such a central part of [Kubernetes](../platforms-and-aoe-services/kubernetes.html) that their use appears self-evident.
|
||||
We've faded out Kubernetes Operators as a standalone recommendation because they are such a central part of [Kubernetes](/platforms-and-aoe-services/kubernetes/) that their use appears self-evident.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
After having very positive experiences, we decided to replace our [ELK stacks](../platforms-and-aoe-services/elk-stack.html) with Loki, primarily for the following reasons:
|
||||
After having very positive experiences, we decided to replace our [ELK stacks](/platforms-and-aoe-services/elk-stack/) with Loki, primarily for the following reasons:
|
||||
|
||||
- Loki is significantly more cost-effective than the storage requirements of Elasticsearch.
|
||||
- The PromQL-like query language, familiar to users of Prometheus, makes it easier for DevOps and SRE teams who already use Prometheus for monitoring to work with logs.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [security, architecture]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We have been transitioning away from using Open Policy Agent at AOE. For alternative solutions, please refer to [Policy as Code](../methods-and-patterns/policy-as-code.html).
|
||||
We have been transitioning away from using Open Policy Agent at AOE. For alternative solutions, please refer to [Policy as Code](/methods-and-patterns/policy-as-code/).
|
||||
|
||||
@@ -30,7 +30,6 @@ The 15-factor model builds upon the original principles by adding:
|
||||
14) **Telemetry**: Implement robust telemetry for monitoring and diagnostics.
|
||||
15) **Authentication and Authorization**: Incorporate strong, centralized authentication and authorization mechanisms.
|
||||
|
||||
|
||||
### Relevance
|
||||
|
||||
For us this rather old pattern is still very relevant and many methods, patterns and practices on our radar are related and enable these pattern in their core. To name a few [Kubernetes](/platforms-and-aoe-services/kubernetes/), [Prometheus](/platforms-and-aoe-services/prometheus/), [Self-Service Infrastructure](/platforms-and-aoe-services/self-service-infrastructure/) or the [API-First Design Approach](/methods-and-patterns/api-first-design-approach/) are very related, others like [Shared Responsibility Models](/methods-and-patterns/shared-responsibility/) are easier to implement based on this pattern.
|
||||
For us this rather old pattern is still very relevant and many methods, patterns and practices on our radar are related and enable these pattern in their core. To name a few [Kubernetes](/platforms-and-aoe-services/kubernetes/), [Prometheus](/platforms-and-aoe-services/prometheus/), [Self-Service Infrastructure](/platforms-and-aoe-services/self-service-infrastructure/) or the [API-First Design Approach](/methods-and-patterns/api-first-design-approach/) are very related, others like [Shared Responsibility Models](/methods-and-patterns/shared-responsibility/) are easier to implement based on this pattern.
|
||||
|
||||
@@ -5,4 +5,3 @@ ring: adopt
|
||||
tags: [architecture, documentation]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -5,4 +5,3 @@ quadrant: methods-and-patterns
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -7,11 +7,11 @@ tags: [ai, architecture, coding]
|
||||
|
||||
### Adopting GitHub Copilot
|
||||
|
||||
We've adopted AI Assisted Programming to enhance our overall efficiency and product quality, with [GitHub Copilot](../tools/github-copilot.html) serving as our primary tool for this purpose.
|
||||
We've adopted AI Assisted Programming to enhance our overall efficiency and product quality, with [GitHub Copilot](/tools/github-copilot/) serving as our primary tool for this purpose.
|
||||
|
||||
Guidelines for its usage have been established, and we continuously refine our practices by sharing best practices and insights within our communities.
|
||||
|
||||
The use of [GitHub Copilot](../tools/github-copilot.html) is currently project-based and requires customer consent. While utilizing it, we remain mindful of potential risks and actively work to mitigate them.
|
||||
The use of [GitHub Copilot](/tools/github-copilot/) is currently project-based and requires customer consent. While utilizing it, we remain mindful of potential risks and actively work to mitigate them.
|
||||
|
||||
### Potential Risks and Mitigation Strategies
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: tools
|
||||
tags: [academy training, frontend, quality assurance]
|
||||
---
|
||||
|
||||
[Cypress](https://www.cypress.io/) continues to prove its value in AOE Group projects and has evolved significantly since early 2022. Cypress remains one of our preferred testing tools for front-end developers, thanks to its robust support for JavaScript and [TypeScript](../languages-and-frameworks/typescript.html). The ease of adoption and implementation, combined with the maintainability of test specifications, has only improved with recent updates.
|
||||
[Cypress](https://www.cypress.io/) continues to prove its value in AOE Group projects and has evolved significantly since early 2022. Cypress remains one of our preferred testing tools for front-end developers, thanks to its robust support for JavaScript and [TypeScript](/languages-and-frameworks/typescript/). The ease of adoption and implementation, combined with the maintainability of test specifications, has only improved with recent updates.
|
||||
|
||||
### Key Updates and Enhancements of the Past Years
|
||||
|
||||
|
||||
@@ -5,8 +5,6 @@ ring: assess
|
||||
tags: [coding, devops]
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
[DevSpace](https://www.devspace.sh/) is an open-source developer tool for Kubernetes that lets you develop and
|
||||
deploy cloud-native software faster. As a "client-only" development tool, it is very simple to develop kubernetes
|
||||
native applications in local or any remote cluster.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
While we continue to recommend the ELK Stack for specific use cases, we now prefer [Loki](../platforms-and-aoe-services/loki.html) for most [Kubernetes](../platforms-and-aoe-services/kubernetes.html)-based setups due to its seamless integration, cost efficiency and user-friendly query language.
|
||||
While we continue to recommend the ELK Stack for specific use cases, we now prefer [Loki](/platforms-and-aoe-services/loki/) for most [Kubernetes](/platforms-and-aoe-services/kubernetes/)-based setups due to its seamless integration, cost efficiency and user-friendly query language.
|
||||
|
||||
@@ -5,4 +5,3 @@ quadrant: tools
|
||||
tags: [security]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ tags: [architecture, ci/cd, quality assurance]
|
||||
- **Alignment with Business Goals**: Ensures that technical decisions are aligned with business goals by making trade-offs explicit and measurable.
|
||||
- **Evolutionary Approach**: Encourages iterative improvement and adaptation, similar to natural selection processes in evolutionary biology.
|
||||
|
||||
[DORA (DevOps Research and Assessment) Metrics](../methods-and-patterns/dora-metrics.html), such as deployment frequency, lead time for changes, mean time to recovery, and change failure rate, provide high-level insights into the overall health and effectiveness of an organization's software delivery practices. By integrating fitness functions into development workflows, teams receive detailed, actionable feedback on specific aspects of their systems, leading to continuous improvement in deployment speed, reliability, and quality.
|
||||
[DORA (DevOps Research and Assessment) Metrics](/methods-and-patterns/dora-metrics/), such as deployment frequency, lead time for changes, mean time to recovery, and change failure rate, provide high-level insights into the overall health and effectiveness of an organization's software delivery practices. By integrating fitness functions into development workflows, teams receive detailed, actionable feedback on specific aspects of their systems, leading to continuous improvement in deployment speed, reliability, and quality.
|
||||
|
||||
By embedding fitness functions into the CI/CD pipeline, teams can ensure that their applications adhere to architectural standards and quality attributes. This proactive approach helps maintain a robust and scalable architecture that provides a solid foundation for the software as it evolves.
|
||||
|
||||
|
||||
@@ -14,4 +14,4 @@ tags: [ai, architecture, coding]
|
||||
- **Code Generation Across Languages**: Supports multiple programming languages and frameworks, making it versatile for different project requirements.
|
||||
- **Automated Documentation**: Generates documentation comments automatically, aiding in better code maintenance and readability.
|
||||
|
||||
See [AI Assisted Programming](../methods-and-patterns/assisted-ai.html) for more information on our adoption of AI tools in our development workflows.
|
||||
See [AI Assisted Programming](/methods-and-patterns/assisted-ai/) for more information on our adoption of AI tools in our development workflows.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: languages-and-frameworks
|
||||
tags: [ai]
|
||||
---
|
||||
|
||||
[LangChain](https://github.com/langchain-ai/langchain) is a framework designed to enhance the development and deployment of applications leveraging natural language processing (NLP) models. It is particularly suited for applications such as "question-answering," "chatbots," or "conversational agents," often utilizing the [Retrieval Augmented Generation (RAG)](../methods-and-patterns/retrieval-augmented-generation.html) pattern.
|
||||
[LangChain](https://github.com/langchain-ai/langchain) is a framework designed to enhance the development and deployment of applications leveraging natural language processing (NLP) models. It is particularly suited for applications such as "question-answering," "chatbots," or "conversational agents," often utilizing the [Retrieval Augmented Generation (RAG)](/methods-and-patterns/retrieval-augmented-generation/) pattern.
|
||||
|
||||
## Key Features
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
title: "OCI Container"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
featured: false
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
OCI Containers are a well-established industry standard now.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Open API"
|
||||
ring: adopt
|
||||
quadrant: tools
|
||||
tags: [architecture]
|
||||
tags: [architecture]
|
||||
---
|
||||
|
||||
The [OpenAPI Specification](https://www.openapis.org/) (OAS) is a broadly adopted industry standard for describing modern REST APIs.
|
||||
@@ -12,7 +12,7 @@ Other initiatives like RAML have [joined](https://blogs.mulesoft.com/dev/api-dev
|
||||
|
||||
The current version OpenAPI v3 added more features to the specification - for example the ability to describe APIs supporting request/callback pattern.
|
||||
|
||||
There is a very good api designer https://www.apicur.io/ and a good mock generator http://microcks.github.io/index.html
|
||||
There is a very good api designer https://www.apicur.io/ and a good mock generator http://microcks.github.io/
|
||||
|
||||
The general tool support is excellent. See https://openapi.tools/
|
||||
|
||||
@@ -27,4 +27,4 @@ For more information on the TM Forum Open API, visit the following resources:
|
||||
- [TM Forum Open API Specifications](https://projects.tmforum.org/wiki/display/API/Open+API+Table)
|
||||
- [TM Forum GitHub Repository](https://github.com/tmforum-apis)
|
||||
|
||||
These additions from TM Forum further enhance the value of the OpenAPI Specification by providing industry-specific standards that help streamline telecommunications operations.
|
||||
These additions from TM Forum further enhance the value of the OpenAPI Specification by providing industry-specific standards that help streamline telecommunications operations.
|
||||
|
||||
@@ -5,4 +5,4 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
[OpenTofu](https://opentofu.org/) is a open source, community driven fork of terraform in response to HashiCorps license changes. It's terraform 1.6 compatible and can act as a drop-in replacement. We watch development and ecosystem growth closely and evaluate a move from terraform to OpenTofu in some projects.
|
||||
[OpenTofu](https://opentofu.org/) is a open source, community driven fork of terraform in response to HashiCorps license changes. It's terraform 1.6 compatible and can act as a drop-in replacement. We watch development and ecosystem growth closely and evaluate a move from terraform to OpenTofu in some projects.
|
||||
|
||||
@@ -5,10 +5,10 @@ quadrant: languages-and-frameworks
|
||||
tags: [frontend, styling]
|
||||
---
|
||||
|
||||
[Panda CSS](https://panda-css.com/) is a feature-rich and highly versatile [CSS-in-JS](../methods-and-patterns/css-in-js.html) library that generates CSS at build time. It provides a great developer experience without the disadvantages of runtime libraries. It is framework-agnostic, but unlike Stylex and Vanilla Extract, it provides JSX-specific features like the `styled` function and style props on top of it.
|
||||
[Panda CSS](https://panda-css.com/) is a feature-rich and highly versatile [CSS-in-JS](/methods-and-patterns/css-in-js/) library that generates CSS at build time. It provides a great developer experience without the disadvantages of runtime libraries. It is framework-agnostic, but unlike [Stylex](/languages-and-frameworks/stylex/) and Vanilla Extract, it provides JSX-specific features like the `styled` function and style props on top of it.
|
||||
|
||||
### Key Features:
|
||||
- Compatible with [React Server Components](../methods-and-patterns/react-server-components.html)
|
||||
- Compatible with [React Server Components](/methods-and-patterns/react-server-components/)
|
||||
- No performance disadvantages compared to runtime libraries
|
||||
- Highly versatile:
|
||||
- Recipes and variants like Stitches
|
||||
|
||||
@@ -5,4 +5,3 @@ quadrant: methods-and-patterns
|
||||
tags: [architecture]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
title: "Puppet"
|
||||
ring: adopt
|
||||
quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
|
||||
@@ -23,4 +23,4 @@ tags: [ai]
|
||||
- **Maintenance overhead**: Regular updates and maintenance of the retrieval system and data sources are required to ensure continued accuracy and relevance, adding to the operational burden.
|
||||
- **Potential for bias**: The retrieval process can introduce biases present in the external data, which can be propagated into the generated content, affecting the fairness and objectivity of the outputs.
|
||||
|
||||
At AOE, we are evaluating [LangChain](../languages-and-frameworks/langchain.html) as a framework for implementing chatbots that allow users to better interact with existing knowledge and ensure that they deliver accurate, contextual, and reliable information.
|
||||
At AOE, we are evaluating [LangChain](/languages-and-frameworks/langchain/) as a framework for implementing chatbots that allow users to better interact with existing knowledge and ensure that they deliver accurate, contextual, and reliable information.
|
||||
|
||||
@@ -5,9 +5,9 @@ quadrant: languages-and-frameworks
|
||||
tags: [frontend, styling]
|
||||
---
|
||||
|
||||
Facebook has released [StyleX](https://stylexjs.com/), an open-source JavaScript syntax and compiler for styling web apps. It combines the developer experience of [CSS-in-JS](../methods-and-patterns/css-in-js.html) libraries with the performance and scalability of static CSS using compile-time tools.
|
||||
Facebook has released [StyleX](https://stylexjs.com/), an open-source JavaScript syntax and compiler for styling web apps. It combines the developer experience of [CSS-in-JS](/methods-and-patterns/css-in-js/) libraries with the performance and scalability of static CSS using compile-time tools.
|
||||
|
||||
It supports frameworks like [React](../languages-and-frameworks/react.html) and [Angular](../languages-and-frameworks/angular.html). Styles are defined using an object syntax and `create()` API, and can be conditionally applied within components.
|
||||
It supports frameworks like [React](/languages-and-frameworks/react/) and [Angular](/languages-and-frameworks/angular/). Styles are defined using an object syntax and `create()` API, and can be conditionally applied within components.
|
||||
|
||||
### Key Features:
|
||||
- **Atomic CSS**: Minimizes CSS output
|
||||
|
||||
@@ -13,11 +13,11 @@ Software libraries and other external dependencies are a major attack vector whe
|
||||
|
||||
- Verify dependency artifact signatures and checksums to detect artifacts that were released or replaced by an attacker.
|
||||
- Raise developer awareness regarding malicious dependencies and issues such as typosquatting in dependency package managers.
|
||||
- Generate [Software Bills of Materials (SBOMs)](../platforms-and-aoe-services/sbom.html) for transparency regarding used software dependencies and to support the automated detection of known vulnerabilities.
|
||||
- Generate [Software Bills of Materials (SBOMs)](/platforms-and-aoe-services/sbom/) for transparency regarding used software dependencies and to support the automated detection of known vulnerabilities.
|
||||
- Evaluate and reduce the number of external dependencies to minimize the attack surface.
|
||||
|
||||
We believe that supply chain security can only be achieved when taking every step of the supply chain into account. Therefore, we utilize the DevSecOps lifecycle and evaluate potential attack vectors and countermeasures for the complete software development and operation lifecycle. As a result, we use the following general measures to improve supply chain security:
|
||||
|
||||
- Secure build, test, and deployment environments with [Zero Trust](../methods-and-patterns/zero-trust/).
|
||||
- Secure build, test, and deployment environments with [Zero Trust](/methods-and-patterns/zero-trust/).
|
||||
- Sign built software artifacts and verify the signature of artifacts before deploying them.
|
||||
- Use static application security testing (SAST) and dynamic application security testing (DAST) to scan for known vulnerabilities and logic flaws before deploying artifacts to production environments.
|
||||
|
||||
@@ -10,4 +10,4 @@ Terraform has become a de facto standard as a cloud-provider-agnostic infrastruc
|
||||
|
||||
Unfortunately, the [license change for HashiCorp products in August 2023](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) has caused [some](https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca) [turmoil](https://zeet.co/blog/the-impact-of-hashicorps-license-change-on-terraform-users-and-providers-what-you-need-to-know) within the open source community. Terraform can no longer be considered truly open source. Of particular concern are the [usage limitations that prohibit "competitive offerings" to HashiCorp's products](https://www.hashicorp.com/license-faq#usage-limitations). The vagueness of this definition, coupled with the fact that HashiCorp can change their interpretation of what constitutes a "competitive offer" at any time, poses a potential liability for agencies and their customers.
|
||||
|
||||
As a result, we are currently [assessing OpenTofu](../platforms-and-aoe-services/opentofu.html) as a drop-in replacement for Terraform. [OpenTofu](https://opentofu.org) is an open source fork under the umbrella of the Linux Foundation, created from the last commit before Terraform's license change.
|
||||
As a result, we are currently [assessing OpenTofu](/platforms-and-aoe-services/opentofu/) as a drop-in replacement for Terraform. [OpenTofu](https://opentofu.org) is an open source fork under the umbrella of the Linux Foundation, created from the last commit before Terraform's license change.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [ci/cd,devops,security]
|
||||
featured: false
|
||||
---
|
||||
|
||||
See [Supply Chain Security](../methods-and-patterns/supply-chain-security.html) for updated recommendations.
|
||||
See [Supply Chain Security](/methods-and-patterns/supply-chain-security/) for updated recommendations.
|
||||
|
||||
@@ -4,4 +4,4 @@ ring: assess
|
||||
quadrant: tools
|
||||
tags: [documentation, architecture]
|
||||
featured: false
|
||||
---
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "Visual Regression Tests for Frontend Developers"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
tags: [coding, frontend, quality assurance]
|
||||
title: "Visual Regression Tests for Frontend Developers"
|
||||
ring: adopt
|
||||
quadrant: methods-and-patterns
|
||||
tags: [coding, frontend, quality assurance]
|
||||
---
|
||||
|
||||
In the realm of frontend development, ensuring that applications not only function correctly but also look as intended across various devices and browsers is paramount. This is where visual regression tests come into play, solving a critical problem faced by developers: detecting unintended visual changes. By automating the comparison of screenshots over time, these tests can identify differences between expected and actual UI appearances, down to the pixel level. In this respect, they exceed and replace some use cases of traditional unit tests, which focus on functional aspects of the code.
|
||||
@@ -11,6 +11,6 @@ Visual regression tests address several challenges. They ensure consistency in t
|
||||
|
||||
Moreover, integrating visual regression tests into development pipelines enhances the reliability of deployments. By catching visual discrepancies early, it prevents potential UI issues from reaching end-users. This not only saves time and resources but also maintains the application's quality and reputation.
|
||||
|
||||
Currently there are several AOE teams that use visual regression tests with [Playwright](../tools/playwright.html) in their daily operations, with more teams expected to adopt this practice in the future.
|
||||
Currently there are several AOE teams that use visual regression tests with [Playwright](/tools/playwright/) in their daily operations, with more teams expected to adopt this practice in the future.
|
||||
|
||||
In summary, visual regression tests are an invaluable tool for frontend developers. They streamline the development process, ensure visual consistency, and maintain high-quality user interfaces, making them an essential part of modern web development workflows.
|
||||
|
||||
Reference in New Issue
Block a user