Our Enterprise DevOps Dispatch is online!
Our weekly dispatch is online. Sign up if you don't want to miss one: https://techaccelerationandresilience.com/short-notes/dispatch-0823
#devops #sre #platformengineering #dispatch #newsletter #techstrategy
https://redd.it/119amr5
@r_devops
Our weekly dispatch is online. Sign up if you don't want to miss one: https://techaccelerationandresilience.com/short-notes/dispatch-0823
#devops #sre #platformengineering #dispatch #newsletter #techstrategy
https://redd.it/119amr5
@r_devops
Tech Acceleration & Resilience
Dispatch #08/23 β Tech Acceleration & Resilience
Platform Engineering is a revolutionary approach to software development and delivery that emphasizes self-service and enables organizations to deliver and scale their products faster and more efficiently than ever before.
π DevOps Isn't Just CI/CD β Let's Talk About Real Deployment Challenges
Hey folks π
I just published a new blog post where I dive into the **real-world complexities of DevOps deployments** β way beyond just wiring up GitHub Actions or Jenkins pipelines.
π Read it here: [https://norbix.dev/posts/devops-deployment/](https://norbix.dev/posts/devops-deployment/)
Hereβs what I cover:
* Why βCI/CDβ is just the **tip of the iceberg**
* Hidden realities like config drift, rollbacks, release approvals, and hybrid infra
* Real-life tips for teams that manage **cloud-native, on-prem, or mixed environments**
* Thoughts on blue/green, canary, GitOps, and platform engineering
π¬ Iβd love your thoughts:
* How do you **handle deployments** in your org?
* Do you manage full lifecycle (build β release β monitor) as part of DevOps?
* Any horror stories (or wins) you'd like to share?
Letβs get beyond the buzzwords and talk actual **deployment engineering**.
\#DevOps #SRE #PlatformEngineering #CI/CD #norbix
https://redd.it/1kie9fi
@r_devops
Hey folks π
I just published a new blog post where I dive into the **real-world complexities of DevOps deployments** β way beyond just wiring up GitHub Actions or Jenkins pipelines.
π Read it here: [https://norbix.dev/posts/devops-deployment/](https://norbix.dev/posts/devops-deployment/)
Hereβs what I cover:
* Why βCI/CDβ is just the **tip of the iceberg**
* Hidden realities like config drift, rollbacks, release approvals, and hybrid infra
* Real-life tips for teams that manage **cloud-native, on-prem, or mixed environments**
* Thoughts on blue/green, canary, GitOps, and platform engineering
π¬ Iβd love your thoughts:
* How do you **handle deployments** in your org?
* Do you manage full lifecycle (build β release β monitor) as part of DevOps?
* Any horror stories (or wins) you'd like to share?
Letβs get beyond the buzzwords and talk actual **deployment engineering**.
\#DevOps #SRE #PlatformEngineering #CI/CD #norbix
https://redd.it/1kie9fi
@r_devops
norbix.dev
DevOps Deployment
A comprehensive guide to deploying a 3-tier application using Docker, Kubernetes, and Helm.
Bringing trust to your CI System
How would you even know if your build pipeline was compromised β not your code, the system that builds it?
That question is basically what pulled me down a rabbit hole last weekend. I was just going back to basics, re-reading the fundamentals of secure software delivery, and somehow landed right back on the one question that always pops up eventually: how much does anyone actually trust CI?
Because if someone quietly got a foothold in a build system, the artifact that comes out the other end still looks completely legitimate. Nothing downstream catches it, because most pipelines are built to just trust the artifact by default. That's the same pattern behind incidents like SolarWinds and Codecov β not application bugs, trust failures in the delivery path itself.
So I went down the rabbit hole properly β the current SLSA framework, provenance, in-toto attestations, the whole "how do you actually prove what happened during a build" question. Turns out the industry's answer is pretty elegant: provenance is a verifiable record of what happened during the build. Attestation is how that record gets proven, cryptographically, at every step after.
A few late nights later, my notes turned into something worth keeping β a handbook I know I'll come back to, more than once. The whole thing distills into one line I keep coming back to:
Git β Build β Artifact β Deploy β Runtime β identity, evidence, and independent verification at every boundary.
If you operate any part of a software delivery path to production, ask yourself that question today.
Read the handbook at https://securesoftwaredelivery.wckd14.xyz/
\#PlatformEngineering #SupplyChainSecurity #SLSA #SSDLC #DevSecOps
https://redd.it/1v7cj9j
@r_devops
How would you even know if your build pipeline was compromised β not your code, the system that builds it?
That question is basically what pulled me down a rabbit hole last weekend. I was just going back to basics, re-reading the fundamentals of secure software delivery, and somehow landed right back on the one question that always pops up eventually: how much does anyone actually trust CI?
Because if someone quietly got a foothold in a build system, the artifact that comes out the other end still looks completely legitimate. Nothing downstream catches it, because most pipelines are built to just trust the artifact by default. That's the same pattern behind incidents like SolarWinds and Codecov β not application bugs, trust failures in the delivery path itself.
So I went down the rabbit hole properly β the current SLSA framework, provenance, in-toto attestations, the whole "how do you actually prove what happened during a build" question. Turns out the industry's answer is pretty elegant: provenance is a verifiable record of what happened during the build. Attestation is how that record gets proven, cryptographically, at every step after.
A few late nights later, my notes turned into something worth keeping β a handbook I know I'll come back to, more than once. The whole thing distills into one line I keep coming back to:
Git β Build β Artifact β Deploy β Runtime β identity, evidence, and independent verification at every boundary.
If you operate any part of a software delivery path to production, ask yourself that question today.
Read the handbook at https://securesoftwaredelivery.wckd14.xyz/
\#PlatformEngineering #SupplyChainSecurity #SLSA #SSDLC #DevSecOps
https://redd.it/1v7cj9j
@r_devops
Secure Software Delivery Architecture
A Platform Engineer's Guide to Trust, Identity, and Software Supply Chains β from Git commit to running workload.