Skills
DevOps brings together the practices that make a change reproducible from the code repository through operation: continuous integration, testing, build, deployment, configuration, secrets, backups, monitoring, and rollback. The objective is not merely automating a command. The gap between the tested environment and the one actually serving users must be reduced, and sufficient evidence retained to understand a failure.
My experience is primarily on managed platforms. Odoo.sh provides development, staging, and production environments, backups, and ERP builds; Vercel handles Next.js application deployment; GitHub Actions runs portfolio checks. I can use and connect these services, read their logs, and prepare a cutover. I distinguish this practice from deep infrastructure administration: I do not yet claim advanced mastery of Kubernetes, networking, infrastructure as code, or operating a production cluster.
Software supply-chain security is part of the skill: image versions, dependencies, provenance, secrets, and pipeline permissions. A backup is useful only when it represents a consistent state and can become a restoration point.
Docker describes hardened images as minimal, continuously patched foundations with verifiable metadata. This development puts software supply-chain security, SBOMs, and image provenance at the center of DevOps practice.
Read the source: DockerThe ERP migration used Odoo.sh environments connected to the GitHub repository. I made adaptations on dedicated branches, ran builds, read migration logs, and restored realistic production copies for acceptance testing. Before cutover, I verified that a complete backup combined the PostgreSQL database and filestore from the same state, prepared the order for restoring integrations, and defined rollback to the last stable state if a critical anomaly prevented recovery.
Result — Production resumed after roughly three hours and no rollback was required. The scenario was nevertheless ready, allowing the cutover to be treated as a controlled operation rather than a bet on the first startup succeeding.
The corporate website is version-controlled on GitHub and prepared for Vercel deployment. I integrated environment variables, quality checks, component and API tests, and Playwright journeys. Choosing Vercel provides a preview and production chain suited to Next.js, but I keep the architecture standard enough to avoid making the platform impossible to leave if requirements change. Candidate acceptance testing must precede cutover, and connected services must be checked after deployment.
Result — The project already has a reproducible chain through previews and control foundations before its future production release. The platform choice remains evaluated by its cost-to-service ratio rather than treated as permanent.
The portfolio uses several testing levels: unit functions under jsdom, components in a Playwright browser, visual regressions, and end-to-end journeys. GitHub Actions runs checks so a change does not depend solely on my local environment. Resend, reCAPTCHA, and Google Tag Manager secrets remain provided through environment variables. External dependencies are simulated in part of the tests, a limitation I document instead of confusing a green suite with complete deployment validation.
Result — More than 170 tests now protect the main behaviors and content relationships. This automation speeds up change while keeping real checks still required at external-service boundaries explicitly identified.
I retain a beginner level, but as a beginner who has already prepared deployments and a critical migration on managed platforms. I can use pipelines, logs, backups, and environment variables. I still lack experience building and operating the infrastructure itself, especially networking, distributed observability, and infrastructure as code.
This skill matters because I often own the complete chain through production. It directly conditions the reliability of my Odoo, backend, and frontend skills: a good fix loses value if it cannot be deployed, monitored, or restored cleanly.
My advice is to prepare rollback before production, verify backups through consistency rather than mere presence, and treat logs as product data. Managed platforms reduce operational work, but they do not remove responsibility for secrets, tests, or understanding what they automate.
Reach a solid intermediate level by being able to describe and automate a simple infrastructure, establish usable observability, and lead a deployment with tested restoration beyond a single managed platform.
I continue studying Docker, minimal images, SBOMs, CI/CD pipelines, and monitoring. My future self-hosted Business Intelligence tool should provide a setting for practicing containers, persistence, backups, metrics, and regular service operation.