Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: fills pages with (better) content #4

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
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
Original file line number Diff line number Diff line change
@@ -1,58 +1,11 @@
= Branching strategy

A branching strategy is a specific approach used by software development teams to manage the development of new features, bug fixes, and other updates within a version control system like Git.
It helps in organizing code changes and ensuring that the final product is stable and maintainable.
Several common branching strategies exist, each suitable for different types of projects and team structures.

== Git Flow

Git Flow is a popular branching strategy proposed by Vincent Driessen.
It introduces a structured branching model with multiple long-lived branches:
- `master`: The main branch containing stable code that is ready for production.
- `develop`: A branch for integrating features and fixes before merging them into the master.
- `feature/*`: Short-lived branches created from `develop` for developing new features.
- `release/*`: Branches for preparing releases; they help in final bug fixing and preparation before merging into `master` and `develop`.
- `hotfix/*`: Used to quickly address critical bugs found in production.

This strategy is suitable for teams following a disciplined release cycle, ensuring stability and quality.

== GitHub Flow

GitHub Flow is a simpler, more streamlined approach predominantly used in continuous integration and deployment environments.
It involves the following:
- `main`: The default branch which always has deployable code.
- `feature/*` or `branch/*`: Short-lived branches created from `main` for new work.
Changes are committed to these branches and merged back into `main` through pull requests.
This ensures that the `main` branch is always stable and deployable.

This strategy is ideal for teams needing rapid deployment and continuous delivery.

== GitLab Flow

GitLab Flow incorporates aspects of both Git Flow and GitHub Flow, providing flexibility based on an organization's deployment needs.
Key branches include:
- `main`: Production-ready code.
- `develop` or `staging`: Integration and testing environments.
- `feature/*`: Branches for new features or fixes, merged into `develop` or `staging`.
- Release management can involve tagging commits on the `main` branch or using specific release branches.

This strategy works well for teams with complex workflows and multiple environments.

== Trunk-Based Development

In trunk-based development, all developers work on a single long-lived branch, commonly referred to as `trunk` or `main`.
Developers frequently commit their changes directly to this branch and continuously integrate their modifications.
This strategy promotes rapid integration and reduces merge conflicts by keeping all code changes in a single place.
Feature branches are avoided or kept extremely short-lived.

Trunk-based development is suitable for high-paced environments where frequent releases and continuous integration are critical.

== Choosing the Right Strategy

Choosing the right branching strategy depends on several factors:
- Team size and structure.
- Frequency of releases.
- Stability and deployment requirements.
- Integration and testing workflows.

By carefully considering these factors, teams can select a branching strategy that opt
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
= Coding, commit and contribution guidelines

WARNING::
This document is generated and a generic example of how a page with "real content" could look like.
It is not a real document and should not be used as a reference.

Effective coding, commit, and contribution guidelines are essential for maintaining a high-quality codebase and fostering productive collaboration within development teams.
These guidelines serve as a blueprint for consistency, clarity, and efficiency in software development.

Expand Down
136 changes: 9 additions & 127 deletions docs/developer-guide/modules/concepts/pages/release-strategy.adoc
Original file line number Diff line number Diff line change
@@ -1,129 +1,11 @@
= Release strategy

A solid release strategy is essential for delivering software updates in an efficient, structured, and repeatable manner.
It encompasses planning, testing, deploying, and managing the software lifecycle to ensure high quality and minimal disruption.

== Defining a Release Strategy

A release strategy outlines the process and guidelines for carrying out software releases.
This includes planning the release cycle, ensuring code quality, coordinating with stakeholders, and managing post-release support.

== Types of Releases

Releases can vary in scope and purpose.
Understanding the different types is crucial for planning and execution.

=== Major Releases

- *Definition*: Major releases introduce significant changes, new features, and possibly breaking changes.
- *Impact*: These releases often require extensive development, testing, and documentation efforts.
- *Versioning*: Incremented in the "X.y.z" format (e.g., 2.0.0).

=== Minor Releases

- *Definition*: Minor releases add new functionality and improvements without breaking backward compatibility.
- *Impact*: They require moderate testing and documentation.
- *Versioning*: Incremented in the "x.Y.z" format (e.g., 1.1.0).

=== Patch Releases

- *Definition*: Patch releases focus on bug fixes, performance enhancements, and security patches.
- *Impact*: These are more frequent and usually require quick testing cycles.
- *Versioning*: Incremented in the "x.y.Z" format (e.g., 1.0.1).

== Release Cycles

Different release cycles cater to various development and business needs.

=== Continuous Deployment

- *Definition*: Automatically deploys code to production as soon as it passes all stages of the CI/CD pipeline.
- *Use Case*: Suitable for teams practicing DevOps and needing rapid, incremental updates.

=== Continuous Delivery

- *Definition*: The software is always in a deployable state; releases are made manually based on business decisions.
- *Use Case*: Ideal for teams balancing rapid updates with controlled release processes.

=== Time-Based Releases

- *Definition*: Releases are scheduled at regular intervals, such as monthly or quarterly.
- *Use Case*: Suitable for predictable planning and aligning with business cycles.

=== Feature-Based Releases

- *Definition*: Releases are based on the completion and readiness of specific features.
- *Use Case*: Ideal for projects driven by significant feature milestones.

== Pre-Release Stages

Ensuring stability and quality before reaching production is critical.

=== Development Environment

- *Purpose*: Where developers write and test their code.
- *Activities*: Code reviews, unit tests, and integration tests.

=== Staging Environment

- *Purpose*: Mimics the production environment for final testing.
- *Activities*: User Acceptance Testing (UAT), performance testing, and integration testing.

== Deployment Strategies

Choosing the right deployment strategy helps manage risks and ensures a smooth transition.

=== Blue-Green Deployment

- *Definition*: Maintain two identical environments (blue and green); one serves live traffic while the other is updated.
- *Use Case*: Minimizes downtime during deployment.

=== Canary Releases

- *Definition*: Gradually roll out changes to a small subset of users first.
- *Use Case*: Early detection of issues with minimal impact.

=== Rolling Updates

- *Definition*: Incrementally deploy updates to different parts of the infrastructure.
- *Use Case*: Helps in mitigating risks by updating in smaller batches.

=== A/B Testing

- *Definition*: Deploy different versions of the software to different user groups to test variations.
- *Use Case*: Useful for gathering user feedback and optimizing features.

== Rollback Plan

A rollback plan is essential to revert quickly in case of issues.

- *Automated Rollback*: Scripts or tools to automate reverting changes.
- *Manual Rollback*: Detailed procedures for manually undoing changes.
- *Database Rollback*: Ensure database changes can be rolled back safely.

== Communication

Effective communication ensures all stakeholders are aware of the release status and any possible impacts.

=== Release Notes

- *Content*: Document key changes, new features, bug fixes, and known issues.
- *Distribution*: Share with stakeholders, users, and support teams.

=== Stakeholder Meetings

- *Purpose*: Keep stakeholders informed and aligned on release progress.
- *Frequency*: Regularly scheduled during the release cycle.

== Post-Release Activities

Post-release activities ensure the release is successful and any issues are promptly addressed.

- *Monitoring*: Continuously monitor the release for performance and stability.
- *Support Plan*: Have a support plan to address user feedback and issues.
- *Incident Reports*: Document any issues and the steps taken to resolve them.

== Conclusion

A robust release strategy is vital for delivering high-quality software efficiently and predictably.
By carefully planning each stage, choosing appropriate deployment strategies, and maintaining clear communication, development teams can minimize risks, enhance product quality, and achieve business goals.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
12 changes: 11 additions & 1 deletion docs/developer-guide/modules/how-to/pages/debugging-guide.adoc
Original file line number Diff line number Diff line change
@@ -1 +1,11 @@
= How to debug
= How to debug

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
10 changes: 10 additions & 0 deletions docs/developer-guide/modules/how-to/pages/get-access.adoc
Original file line number Diff line number Diff line change
@@ -1 +1,11 @@
= How to get access rights

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
65 changes: 33 additions & 32 deletions docs/developer-guide/modules/how-to/pages/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,8 @@ Intention of this section is to provide guides for developers on how to perform
This should help improve productivity and consistency in the development process.
Be concise and to the point, assume the reader is competent in technology and tools used in the project.
See
https://diataxis.fr/how-to-guides/[How-to guides in diataxis] for more information.
https://diataxis.fr/how-to-guides/[How-to guides in diataxis]
for more information.


What to include::
Expand All @@ -35,55 +36,55 @@ External resources::
* https://github.com/spring-projects/spring-framework/wiki/Build-from-Source#import-into-your-ide[Spring Framework Build from Source]
* https://go.dev/doc/contribute.html[Go Contributing Guide]

.Dependency Maintenance Routine Guide
.Dependency maintenance routine guide
[example]
=====
Dependency Maintenance Routine Guide
Dependency maintenance routine guide

This section provides a checklist for managing dependency updates in the software project.
Regular maintenance ensures the incorporation of improvements, security fixes, and new features while maintaining system stability.
Following a structured routine enables smooth handling of dependency updates and reduces technical debt.

Process Overview:

. *Review Merge Requests by Dependabot / Renovate*:
- Check the changes proposed in the MR, including diff and commit messages.
- Understand the context and impact of the updates.
. *Review merge requests by dependabot / renovate*:
* Check the changes proposed in the MR, including diff and commit messages.
* Understand the context and impact of the updates.

. *Dependency Updates*:
- Verify the list of updated dependencies and their version changes.
- Review release notes for breaking changes, deprecations, or relevant fixes.
. *Dependency updates*:
* Verify the list of updated dependencies and their version changes.
* Review release notes for breaking changes, deprecations, or relevant fixes.

. *Assignment and Ownership*:
- Assign the MR to yourself or the appropriate team member for detailed review and feedback.
. *Assignment and ownership*:
* Assign the MR to yourself or the appropriate team member for detailed review and feedback.

. *Testing Updates*:
- Test changes locally or in a staging environment to ensure compatibility.
- Use automated pipelines for regression testing where applicable.
. *Testing updates*:
* Test changes locally or in a staging environment to ensure compatibility.
* Use automated pipelines for regression testing where applicable.

. *Pipeline Validation*:
- Verify the execution of pipelines and resolve any errors.
- Regularly monitor nightly tests for hidden issues.
. *Pipeline validation*:
* Verify the execution of pipelines and resolve any errors.
* Regularly monitor nightly tests for hidden issues.

. *Merge Changes*:
- Merge updates once testing and reviews are complete.
- Follow project-specific commit message guidelines.
. *Merge changes*:
* Merge updates once testing and reviews are complete.
* Follow project-specific commit message guidelines.

. *Dockerfile and CI Images*:
- Check and update Dockerfiles for base images and tools.
- Test and verify new image builds before deployment.
. *Dockerfile and CI images*:
* Check and update Dockerfiles for base images and tools.
* Test and verify new image builds before deployment.

. *Security Considerations*:
- Prioritize and assess the impact of security fixes.
- Coordinate urgent releases for high-severity vulnerabilities.
. *Security considerations*:
* Prioritize and assess the impact of security fixes.
* Coordinate urgent releases for high-severity vulnerabilities.

. *Helm Charts and Falco Rules*:
- Review changes in Helm charts and configuration.
- Test new or updated Falco rules and resolve false positives.
. *Helm charts and falco rules*:
* Review changes in Helm charts and configuration.
* Test new or updated Falco rules and resolve false positives.

. *Monitoring Post-Update*:
- Monitor for new errors or events caused by updates.
- Address issues promptly and iterate as needed.
. *Monitoring post-update*:
* Monitor for new errors or events caused by updates.
* Address issues promptly and iterate as needed.

=====
====
10 changes: 10 additions & 0 deletions docs/developer-guide/modules/how-to/pages/local-setup.adoc
Original file line number Diff line number Diff line change
@@ -1 +1,11 @@
= How to install a local setup (SEU/IDE/SEES)

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Original file line number Diff line number Diff line change
@@ -1 +1,11 @@
= How to handle maintenance routines
= How to handle maintenance routines

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
10 changes: 10 additions & 0 deletions docs/developer-guide/modules/how-to/pages/onboarding.adoc
Original file line number Diff line number Diff line change
@@ -1 +1,11 @@
= How to onboard (I am new, what should I do)

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
At vero eos et accusam et justo duo dolores et ea rebum.
Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
Loading
Loading