这是indexloc提供的服务,不要输入任何密码
Skip to content
This repository was archived by the owner on Sep 9, 2025. It is now read-only.
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions app-development-map/v1alpha2/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ This section outlines a framework for classifying tools relevant to cloud-native
| How is the project best described? | Tool, Project |
| In which development activity is this tool used? | Architecture, Planning, and Collaboration; Coding; Building and Running the Application. |
| How often does a developer use this tool? | As a developer this will be part of their day-to-day usage. |
| How does this tool help/improve developer productivity? | The tool enables the developer to rely on a well-defined programing model to implement their business logic. <br><br> The configuration of a Knative Function has a reduced scope and is easier to understand compared to Kubernetes configurations needed to achieve the same outcome without using Knative. <br><br> The tooling (CLI) empowers the developer to do local testing. <br><br> The tooling (CLI) enables the developer to build OCI compliant images without needing to worry about Dockerfiles etc. |
| How does this tool help/improve developer productivity? | The tool enables the developer to rely on a well-defined programming model to implement their business logic and seamlessly build and deploy it to a Kubernetes environment. <br><br> The configuration of a Knative Function has a reduced scope and is easier to understand compared to Kubernetes configurations needed to achieve the same outcome without using Knative. <br><br> The tooling (CLI) empowers the developer to do local testing. <br><br> The tooling (CLI) enables the developer to build OCI compliant images without needing to worry about Dockerfiles etc. |
| Which cloud-native principles and good practices does this project promote? | Serverless applications; Event-driven applications (adhering to CloudEvent specification). |
| When and why did a developer learn about this tool/project/spec? | During architecture and design phase. |
| Does this tool help other teams/roles to collaborate with developers? | Yes. The tool separates the tasks of the developer from platform tasks. The interface between those two groups is given by the Knative architecture (serving/eventing) and consequently can enable good collaborations and a common language for exchange between the developer and the platform team. |
Expand Down Expand Up @@ -230,5 +230,5 @@ This section outlines a framework for classifying tools relevant to cloud-native
| ---------------------------------- | --------------------------------------------------------- |
| Cloud Native Application Developer | The goal of the application developer is to create applications that fulfill business requirements (functional requirements) and solve business problems. Developing a cloud native application means that the application is built in a cloud-native way leveraging cloud-qualities like scalability, resilience and flexibility as central cross-functional requirements of the app. |
| Inner Development Loop | The inner development loop is an iterative process performed by a single developer when locally writing, building and debugging code. The process ends once the developer checks the source code into a source code repository e.g., via a pull request. This event starts the outer-development loop. |
| Outer Development Loop | The outer development loop is started once the code provided by the developer is checked into a source code repository e.g. via a PR. This starts automated processes like CI/CD pipelines that e.g. build your code, execute integration tests, execute compliance checks and finally brings the artifacts to a shared environment like a cluster. |
| Outer Development Loop | The outer development loop is started once the code provided by the developer is checked into a source code repository e.g. via a PR. This starts automated processes like CI/CD pipelines and GitOps processes that e.g. build your code, execute integration tests, execute compliance checks and finally synchronizes the artifacts to a shared environment like a cluster. |
| Preview Environment | Preview environments are cloud environments that enable an isolated (ephemeral) setup to test code changes. They are usually short-lived and have a defined life cycle. The life cycle starts with the code change trigger, usually a pull request, and ends with the code change's merge. |