chore: update docs/about.md [20260712-2103]

This commit is contained in:
github-actions[bot]
2026-07-12 21:04:16 +00:00
committed by GitHub
parent c1b52c521f
commit c369941a51

View File

@@ -16,7 +16,7 @@ Suggesting improvements and best practices or applying quality standards and aut
In a service driven IT sector (with calculated ambiguities and many hidden interests) the product is the hours billed by the consultant, being almost irrelevant the **content of the job and the delivered quality**. It is thus too common to find technical solutions under the policy of applying "the most difficult, non-standard, slowest and most obfuscated way possible" as a competitive element ([the hard way](https://www.fairwinds.com/blog/never-should-you-ever-in-kubernetes-1-do-k8s-the-hard-way) and doing weird things). This does not scale. Being ambiguous in JDs (not to say dishonest) without clarifying the real content of the job is easy and very well paid.
**Ambiguities about DevOps term**. Development of new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of devops specialists. DevOps professionals develop IaC and CI/CD pipelines with standard tools and code, ideally with a [cattle service model](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle), GitOps patterns & [kubernetes](https://www.nextplatform.com/store/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/1654000) among other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with [client-go skills](https://itnext.io/generically-working-with-kubernetes-resources-in-go-53bce678f887), a developer of devops/kubernetes/monitoring tools). In addition, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Moreover, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin. Maybe DevOps should be renamed as OpsDev to avoid misunderstandings.
**Ambiguities about DevOps term**. Development of new ad-hoc devops tools and ad-hoc monitoring solutions should not be the role of devops specialists. DevOps professionals develop IaC and CI/CD pipelines with standard tools and code, ideally with a [cattle service model](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle), GitOps patterns & [kubernetes](https://www.nextplatform.com/store/2021/08/02/kubernetes-expands-from-containers-to-infrastructure-management/1654000) among other responsabilities such as application monitoring. The development of devops tools for kubernetes with i.e. client-go should be clearly mentioned in a JD as "software development of devops tools for kubernetes with client-go" (suitable for a software engineer with [client-go skills](https://itnext.io/generically-working-with-kubernetes-resources-in-go-53bce678f887?gi=d8016dbe6b59), a developer of devops/kubernetes/monitoring tools). In addition, a DevOps specialist should not be a fullstack developer who occasionally does QA + DevOps + Cloud Design/Ops. Moreover, avoid confusing terms to justify these different backgrounds by creating two roles like DevOps Software Developer and DevOps SysAdmin. Maybe DevOps should be renamed as OpsDev to avoid misunderstandings.
A tech stack is not relevant compared to the way technology is managed. You could have the best tool and run into trouble by taking the risk of applying an unsupported or not recommended[^1] approach.
@@ -125,8 +125,8 @@ These are the core tools and frameworks that have been or are significant in my
- [Jenkins Configuration as Code](https://www.jenkins.io/projects/jcasc) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Standardizing Jenkins master configuration via declarative YAML, eliminating configuration drift and manual UI administration.
- [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli) <span class='md-tag md-tag--secondary'>[GUIDE]</span> — Command-line interface for managing and triggering jobs in Jenkins automation server.
- [Jenkins Remote Access API](https://www.jenkins.io/doc/book/using/remote-access-api) <span class='md-tag md-tag--secondary'>[GUIDE]</span> — Programmatic REST API endpoints for Jenkins integration and orchestration.
- [GitLab CI/CD](https://docs.gitlab.com/ee/ci) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Built-in continuous integration and delivery engine of GitLab, supporting declarative YAML pipeline specifications.
- [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Cloud-hosted CI/CD pipeline service by Microsoft, supporting both Windows, Linux, and macOS environments.
- [GitLab CI/CD](https://docs.gitlab.com/ci) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Built-in continuous integration and delivery engine of GitLab, supporting declarative YAML pipeline specifications.
- [Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Cloud-hosted CI/CD pipeline service by Microsoft, supporting both Windows, Linux, and macOS environments.
- [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Automatic generation of API client libraries and server stubs from OpenAPI/Swagger specifications.
- [Postman](https://www.postman.com) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — The industry-standard platform for API design, testing, mock servers, and automated collection runs.
- [Terraform Kubernetes Provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) <span class='md-tag md-tag--success'>[DE FACTO STANDARD]</span> — Official Kubernetes provider for Terraform, enabling declarative deployment and management of Kubernetes resources using HashiCorp Configuration Language (HCL).