devopsy.kinsta.cloud

Tag: CI/CD

Survey Surfaces Multiple Mobile Application Release Management Headaches

A survey of 300 mobile engineers in the U.S and the United Kingdom (UK) working for organizations with 500 to 10,000 employees finds, on average, respondents are spending five hours per release on low-value tasks involving manual steps, coordination issues and approval bottlenecks, translating into 130 wasted engineering hours annually per developer.

Published by Runway, a provider of a software-as-a-service (SaaS) platform for managing mobile application releases, the survey finds more than three-quarters (77%) said their teams experience incidents requiring delays or hotfixes every three to five releases. Most teams (86%) spend a significant amount of time firefighting instead of building features, the survey also finds.

Despite those issues, however, most respondents said it was either very unlikely (9%) or only somewhat likely that their current release process could lead to missed deadlines, delayed features or negative user impact. Only 17% believe it is somewhat likely that inefficiencies in their current release process would lead to such issues.

Just over half (51%) also view their processes as being “somewhat” efficient, even though 52% also report spending about a third of each release cycle on non-productive or low-value tasks.

Only 11% report that their process is very efficient. Two-thirds also agree that improving centralized release coordination would have a significant (19%) or at least moderate (47%) impact on their processes.

Runway CEO Gabriel Savit said the survey makes it clear that as the overall pace of mobile application development accelerates, the teams building these applications are not becoming more efficient, resulting in higher costs. The challenge is that awareness of the issue is limited because of a general lack of observability and automation, he added.

Much of that issue can be traced back to the tools being employed by mobile application development teams, noted Savit. For example, most teams are relying on general-purpose tools such as project management applications (81%) and communication platforms (68%) for release coordination, including Jira/Asana software (81%), Slack (68%), continuous integration/continuous delivery (CI/CD) tools (53%) and spreadsheets (47%).

Not surprisingly, manual steps (49%) top the list of frustrations, followed by context switching (42%), and cross-functional coordination (41%). Respondents estimated that better communications, processes and collaboration across releases could have prevented 63% of uncaught incident issues.

It’s not clear to what degree these issues are more challenging to manage when building mobile applications but end user tolerance for any type of mobile application quality issue is notoriously low. It’s simply too easy for them to switch to another application. As more individuals participate in the development of these applications in the age of artificial intelligence (AI), it’s only a matter of time before the number of applications being simultaneously built is likely to overwhelm existing processes, making it even more critical to prevent quality issues, noted Savit. The issue at hand now is determining to what degree to revamp those processes now versus waiting for the inevitable crisis, he added.

Ultimately, each organization is going to have to revisit how they build and deploy applications in the AI era. The only thing left to determine is the how and when, as the pace of application development continues to steadily increase beyond what any workflow designed for a previous era of software development can effectively support.

August 12, 2025
Special Agents, StackGen Drives DevOps Deeper Into Infrastructure
Amidst the noise created by the various hype engines attempting to tell us that DevOps is dead, we know that a) of course it isn’t, but b) there are indeed deeper forces at work that promise to automate a wider transept of the backend management and orchestration element of the software application development lifecycle.

Too honest for a mission statement and too long for a t-shirt slogan, that statement might go some way to explaining StackGen’s efforts to reinvent itself. The company that was once an infrastructure as code (IaC) specialist now wants to be known as an autonomous infrastructure technology purist. Driving this evolution is (spoiler alert, you know the answer already) the proliferation and ubiquity of agentic AI services.

Golden Path Turbo Booster?

The company’s Autonomous Infrastructure Platform features AI agents to build and manage cloud infrastructure with autonomous capabilities. This is not DevOps with agentic golden path turbo boosters; this is a deeper repositioning of DevOps for the agentic age, where AI-native operations handle infrastructure management with an appreciation for organizational intent.

In other words, it’s DevOps that can dynamically create infrastructure services that align with business needs and application requirements.

“We’re witnessing a DevOps evolution that moves us from ‘you build it, you run it’… to ‘AI builds it, AI runs it’ going forwards,” said Sachin Aggarwal, CEO and co-founder of StackGen, speaking to Techstrong group directly this weekend. “This changes what it means to be a DevOps engineer, i.e., instead of writing configuration files, engineers define business intent and let AI handle implementation. Traditional approaches rely on fixed golden paths, but the future is AI that dynamically understands what your applications and organizational needs.”

Aggarwal claims that StackGen’s autonomous platform represents, validates and delivers this leap. It’s a place – across this latest chasm – where AI doesn’t just follow procedures, it makes reasoning decisions about infrastructure requirements and adapts in real-time. “Within five years, the most successful DevOps teams will be those who can orchestrate AI agents rather than manage infrastructure manually,” he said.

Painful Provisioning Procedures

Keen to illustrate our pre-agentic inefficiencies, StackGen points to surveys that state developers spend around a quarter of their time on infrastructure provisioning instead of building features. Other market analysis suggests that the shift toward AI-managed infrastructure is already underway. Even the naysayers in this space admit that we’re looking at an immediate future where, well before the end of this decade, infrastructure-related tasks will be executed semi-autonomously by AI.

“We’re pioneering a new category while the industry remains anchored to legacy infrastructure flows,” asserted Aggarwal. “When a developer can build a complete application in 30 minutes, but it takes days to deploy and secure it, you have a talent optimization crisis. AI tools now let developers build full-stack apps (think Spotify-style apps with authentication services and streaming capabilities) in 30 minutes. But deploying, securing and managing that infrastructure still takes days of manual DevOps work.”

Aggarwal says that recent incidents like SaaStr’s database deletion by Replit’s AI agent show what happens when we try to accelerate infrastructure operations without proper governance. He is confident that StackGen’s Autonomous Infrastructure Platform bridges this gap with AI agents that can provision, secure and manage infrastructure at the same speed developers create applications.

Futurum Analyst Perspective

“A myriad of infrastructure automation tools and platforms exist, and many (if fewer) tools and platforms enable infrastructure autonomy. Most, if not almost all, of them incorporate IaC or some analogy of IaC as the implementation component of the automation or autonomous operation. But we don’t know of one, until now, that takes IaC generation as its foundation point,” explained Guy Currier, analyst at The Futurum Group.

Currier states that this foundational grounding question is the key point in assessing the relaunch of StackGen as an infrastructure automation company. He explains that StackGen’s earlier focus was on the speedy, reliable and effective generation of IaC that takes an application’s code, needs, scenario and points in the lifecycle as its input channels.

“Recasting this as a launching point for infrastructure autonomy, StackGen does not have to rely on the operator’s guidance – even in prompt form, like artificial AIaC – to configure, deploy and provision infrastructure for an application, and get started managing it,” clarified Currier. “That means that StackGen promises to require much less direction to operate… which is an inverse way of saying that it is likely to be more autonomous, at a whole new level, than any vendor offers we have seen to date. It appears to be an appropriately safe, human-supervised autonomy, with agent classes built to guide, limit, remediate and escalate the autonomous actions of the operating agents.”

Operating Pillars, Seven Agents

StackGen’s vision is built around four self-operating pillars (with some seven agents) delivered by specific AI agents that solve real enterprise infrastructure problems.
- StackBuilder which generates and launches compliant infrastructure from application intent with automated pipeline fixes, enterprise governance and proven automation workflows.
- The StackFinder agent will automatically discover and onboard existing infrastructure.
- StackGuard handles compliance and security posture management by scanning and detecting security and compliance policy violations and suggesting remediations.
- StackAnchor performs drift detection and remediation by scanning and preventing configuration drift as soon as it occurs.
- The StackScribe agent ensures that all learned knowledge is validated and generalized before being integrated into the organizational knowledge base. Together, these components supply context, policies and controls to all AI agents, ensuring coordinated and compliant autonomous operations.
- Designed with reliability engineers in mind, StackHealer’s automated remediation and root cause analysis frees them to focus on reliability improvements rather than firefighting.
- StackOptimizer, which provides cost and performance optimization by analyzing infrastructure performance and cost, suggesting optimal sizing, re-sizing, or re-architecting to improve latency and efficiency.
In terms of its technology’s real-world applicability, CEO Aggarwal says that (unlike startups that are created on a technology-first approach), StackGen was built from real enterprise pain points identified through partnerships with companies. He says that each agent is designed to solve specific use cases that infrastructure teams face daily. There is an autonomy ON/OFF switch too (or at least a regulator valve) here; the platform’s configurable autonomy levels enable organizations to start with copilot capabilities (where AI recommends actions and humans approve) and evolve toward autopilot operations as their infrastructure maturity increases.
July 29, 2025
Bitrise to Invest $3M in DevOps Cloud for Mobile Apps in EU

Bitrise, a provider of a DevOps platform for building mobile applications, plans to invest $3 million to create data centers in the European Union (EU) that meet sovereign cloud requirements.

Company CEO Barnabás Birmacher said Bitrise has spent much of the past year integrating its stack and consolidating the infrastructure it needs to support its platform in the U.S. Now, Bitrise is taking the next step toward ensuring that any data used to build a mobile application doesn’t leave the EU at a time when many organizations are either voluntarily deciding to depend less on IT infrastructure in the U.S. or are being required to use IT infrastructure in a specific geographic region.

To satisfy those requirements, Bitrise is acquiring the server and storage infrastructure it requires, which is then housed in a data center facility in Amsterdam that is owned by a third-party provider. That approach ensures that at any point necessary those servers and storage systems can be moved to another data center, noted Birmacher.

Regardless of location, the data centers will be based on the same Apple M4 and Linux-based infrastructure that Bitrise has built a DevOps platform on top of to streamline the building and deployment of mobile applications.

It’s not clear how fragmented software engineering is about to become as teams are required to ensure that application development projects only access data located in specific regions. Many DevOps teams have been relying on software-as-a-service (SaaS) application platforms that are designed to scale out across multiple geographic regions as additional compute resources have been needed. With the rise of sovereign cloud requirements, however, providers of those platforms need to ensure that any data being accessed never leaves a specific region.

That issue can be especially challenging for organizations that may have relied on highly distributed teams of developers that may reside in multiple countries.

In fact, one of the reasons more organizations are relying on the managed DevOps services that Bitrise provides is to help minimize that complexity, said Birmacher.

As the pace of mobile application development continues to accelerate, more organizations are looking to rely on managed DevOps services, added Birmacher. They simply can’t afford to not only only build a DevOps platform, but also maintain, update and secure it, he noted. That’s especially the case when it comes to building mobile applications simply because there isn’t a lot of forgiveness when it comes to, for example, having to rollback an application once it’s been made available in an app store, so ensuring that every test has been properly conducted is crucial, said Birmacher.

Regardless of who actually manages a DevOps environment, the need to continuously update mobile applications created additional challenges. End users expect that new features and capabilities will be added at a regular cadence. The number of organizations that can afford to invest in their own DevOps environment, as a percentage of those building mobile applications, remains comparatively small. So for the bulk of them, the only way to ensure best software engineering practices are being consistently followed is, after all, to rely on a service.

July 2, 2025
Survey: Pace of Increased Adoption of GitOps Varies Widely

A survey of 660 software development professionals finds 93% have embraced GitOps as a methodology for building and deploying software, with 68% planning to increase usage.

Conducted by Octopus Deploy, a provider of an automation platform for releasing software, the survey finds another quarter (25%) plan to retain their current usage compared to 7% that plan to reduce or stop GitOps usage.

Steve Fenton, director of developer relations for Octopus Deploy, said the survey also makes it clear that GitOps maturity levels also tend to vary considerably. For example, under one-third of organizations use GitOps across less than 20% of their production systems. The survey also finds only 35% of respondents that have adopted GitOps make use of continuous reconciliation and automatic rollback mechanisms. That suggests that many organizations might only be going so far as to house infrastructure-as-code (IaC) configurations alongside source within a centralized Git repository.

GitOps, at its core, refers to the process of automating the provisioning and management of IT infrastructure using a set of best practices that extend to include IaC tools. Ideally, a GitOps workflow should ensure a system is managed declaratively, automatically pulls the desired state declarations from the source, stores that data in a way that enforces immutability and versioning, and then provides some way to observe those interactions.

Once infrastructure is managed with code, it becomes easier to converge the management of IT operations and application deployment. Kubernetes, meanwhile, provides an ideal GitOps platform because it presents a standard set of application programming interfaces (APIs) that enable clusters to automatically pull code as required versus requiring an IT team to manually push code out to a platform.

Regardless of the level of GitOps maturity, there tends to be a high correlation between adoption of GitOps and modern IT platforms such as Kubernetes, noted Fenton. In general, many organizations are typically inclined to rethink legacy processes whenever a new platform is adopted, he added. In fact, it’s not uncommon for a team that has adopted GitOps to deploy microservices-based applications to be working along software engineering teams that are using legacy approaches to deploy more monolithic applications, said Fenton.

A GitOps workflow should ultimately make it simpler for IT operations to achieve continuous delivery of applications, a goal that has remained elusive despite the widespread deployment of continuous integration/continuous delivery (CI/CD) platforms. In fact, while CI is widely used to build applications, the percentage of organizations consistently using CD to deploy software has remained comparatively small.

It’s not clear to what degree the rise of platform engineering as a methodology for managing DevOps workflows at scale might drive increased adoption of GitOps. The one thing that is certain is that as the pace of application development continues to accelerate in the age of artificial intelligence (AI), the need to revisit software engineering workflows will become apparent. The only issue to be resolved now is determining how much to revamp existing workflows versus opting to simply start over again from scratch.

June 30, 2025
Revolutionizing CI/CD: A Framework for Integrating Generative AI Across the Software Delivery Lifecycle
As a DevOps expert, I’ve witnessed firsthand the transformative power of automation and continuous improvement. Today, I’m excited to share a framework that takes our practices to the next level by integrating generative AI into the software delivery lifecycle. This approach not only streamlines our processes but also enhances the quality and efficiency of our deliverables.

The Gen AI-Powered CI/CD Framework

Here’s a step-by-step guide to building and implementing a generative AI framework for CI/CD:

Automated Code Generation and Review
1. Implement GitHub Copilot or Amazon CodeWhisperer for AI-assisted coding.
2. Use AI-powered static code analysis tools like SonarQube or Amazon CodeGuru Reviewer.
Action: Integrate these tools into your IDE and Git workflows, such as GitHub Actions.

Intelligent Test Generation
1. Leverage tools like Diffblue Cover for automated test case generation.
2. Use AWS DevOps Guru to identify areas needing additional testing based on historical data.
Action: Implement AI-generated tests in your test suites and CI pipelines.

Dynamic Infrastructure Provisioning
1. Utilize AWS CloudFormation or AWS CDK with AI-enhanced templates.
2. Implement predictive scaling using Amazon EC2 Auto Scaling with ML-powered forecasting.
Action: Create AI-driven IaC templates and integrate them into your deployment processes.

Automated Security Scanning
1. Integrate Amazon Inspector for AI-powered vulnerability assessments.
2. Use AI-enhanced SAST/DAST tools like Snyk, Checkmarx, or Veracode.
Action: Implement these scans in your CI/CD pipeline, triggered by code commits.

Intelligent Deployment Strategies
1. Implement AI-driven canary deployments using AWS CodeDeploy.
2. Utilize Amazon SageMaker to build ML models for predicting deployment success.
Action: Integrate these predictive models into your deployment decision-making process.

AI-Enhanced Monitoring and Alerting
1. Leverage AWS CloudWatch with AI-powered anomaly detection.
2. Implement predictive alerting using tools like Datadog or New Relic’s AI capabilities.
Action: Set up AI-driven alert thresholds and automated incident response workflows.

Continuous Feedback and Optimization
1. Use AI to analyze user feedback and application logs (AWS Comprehend for sentiment analysis).
2. Implement ML models to correlate code changes with performance metrics.
Action: Create dashboards that visualize AI-derived insights for continuous improvement.

Documentation and Knowledge Management
1. Utilize GitHub CoPilot or AWS CodeWhisperer to generate and update documentation automatically.
2. Implement AI-powered chatbots for internal knowledge sharing.
Action: Set up automated documentation pipelines triggered by code or configuration changes.

Implementation Strategy
1. Assessment: Evaluate your current CI/CD pipeline and identify areas where AI can add the most value.
2. Tool Selection: Choose AI-powered tools that integrate well with your existing stack. Consider AWS services for seamless integration if you’re already in the AWS ecosystem.
3. Pilot Project: Start with a small, non-critical project to test your AI-enhanced CI/CD framework.
4. Training: Upskill your team on AI concepts and the new tools you’re introducing.
5. Gradual Roll-out: Implement the framework in phases, starting with code generation and review, then moving through testing, deployment and monitoring.
6. Measure and Iterate: Use metrics like deployment frequency, lead time and change failure rate to assess the impact of your AI-enhanced pipeline.
7. Scale: Once proven effective, scale the framework across all your projects and teams.
Challenges and Considerations
- Data Privacy: Ensure that your AI tools comply with data protection regulations.
- AI Bias: Regularly audit your AI models for biases in code suggestions or deployment decisions.
- Over-reliance: Maintain a balance between AI assistance and human expertise.
Conclusion

Integrating generative AI into your CI/CD practices isn’t just about adopting new tools — it’s about reimagining the entire software delivery lifecycle. This framework provides a roadmap for leveraging AI to enhance every stage of your pipeline, from code generation to deployment and monitoring.

By implementing this framework, you’re not just optimizing your current processes; you’re future-proofing your DevOps practices. The combination of AI-driven insights and human expertise will lead to faster, more reliable software delivery and ultimately, better products for your end-users.
June 30, 2025
Compliance in the Age of AI: Why Strong CI/CD Foundations Matter
In the age of AI-driven development, teams face a dual imperative: Harness the speed and creativity of code-generation tools while upholding the strictest standards of security, privacy and regulatory compliance. Nowhere is this more critical than in regulated environments — think banking or healthcare — where a single misstep can expose sensitive customer data or run afoul of GDPR, PSD2 and other consumer-protection mandates. How, then, can modern enterprises leverage AI to increase efficiency without increasing risk?

The answer lies in a rock-solid CI/CD foundation that weaves governance into every stage of the software lifecycle.

Balancing Speed Versus Control

CI/CD, continuous integration and continuous delivery, was designed to catch problems early in the development lifecycle and keep pace with rapidly changing market demands. It’s the foundation of DevOps; everything flows from your CI/CD pipeline, so getting it right is critical.

AI can dramatically shorten build cycles and accelerate code creation. Developers can now use tools like Cursor, Windsurf, Claude Code, Copilot and other AI assistants to generate code in seconds. But every burst of productivity brings potential risk. Just as human-written code needs to be rigorously tested against compliance standards, AI-generated code does too.

The efficiency gains AI promises can tempt teams to cut corners on essential checks and controls. Engineering and DevOps leaders must arm themselves with tools and processes that keep compliance front and center.

Rigorous Review and Testing for AI-Generated Code

Whether code comes from carbon-based lifeforms or large language models, more code tends to mean more bugs, more logic errors and potentially more security vulnerabilities. A robust CI/CD foundation enables automated audits, compliance checks and tests across every commit and build, ensuring issues are flagged and fixed before they hit production. For example:
- End-to-end testing of critical workflows on every build. This is especially vital for mobile apps, where a faulty update can have catastrophic consequences.
- Peer-review pipelines augmented by AI-driven alerts that highlight code quality issues, compliance gaps, or untested branches before merge.
- Progressive delivery patterns — canaries and feature flags — that limit blast radius and enable automatic rollback if an AI-assisted feature misbehaves in production.
These practices ensure that every line of AI-generated code meets the same security and quality bar as handcrafted work, while still letting teams move at AI-speed.

Leveraging AI as the Compliance Guardrail

Rather than viewing AI solely as a code generator, forward-thinking organizations deploy AI agents as compliance guardians within their CI/CD pipelines. A mature CI/CD system does more than move bits from repo to production — it enforces policy at scale. Key practices include:
- Integrating privacy-impact and vulnerability scans into every pull request to spot risky dependencies or misconfigurations early.
- Automating release approvals that require explicit sign-off on consumer-protection rules before pushing updates to real users.
- Maintaining an immutable audit trail of every build, test and deployment step — crucial evidence when regulators come knocking.
With these guardrails in place, compliance becomes a predictable, automated process rather than a last-minute bottleneck.

Controlling the Agency of AI Agents

AI agents can serve as powerful governance partners, continuously monitoring for compliance issues, detecting security vulnerabilities and ensuring that all code — whether human or AI-generated — meets regulatory requirements. But when AI agents make autonomous decisions, a new level of risk emerges: Agents can act without full contextual judgment and tracing of why an agent took a given action.

A strong CI/CD toolchain and proper configuration let organizations define the boundaries in which AI agents operate, including automated checks, verifications and controls.

Governance as a Competitive Advantage

In the AI era, governance isn’t just about avoiding problems — it’s about building trust and enabling faster, more confident innovation. Organizations with strong CI/CD foundations can leverage AI’s power while maintaining control over quality, security and compliance.

Practical governance strategies include:
- Ensure your CI/CD pipeline can handle the increase in volume of AI-generated code. Define clear boundaries and explicit policies for when and how AI tools are used.
- Speed is your edge, but control is your game-changer. With the right CI/CD and AI guardrails, you can make your release cadence and robust testing your competitive advantage.
- Foster a governance-aware, AI-curious culture. Train developers on AI and compliance requirements in parallel, demonstrate best practices and establish clear escalation paths.
By embedding security, privacy and compliance checks into your CI pipeline — and using AI agents for continuous auditing — you can unleash AI’s potential without compromising trust or compliance. This approach also reduces implementation complexity by leveraging your already approved, vetted and secure CI environment.

Build the DevOps Foundations Now to Scale in an AI-Driven Future

The era of AI has already brought massive productivity gains across the software development lifecycle, but implementing AI code generation tools or AI agents without the proper guardrails in place leaves organisations open to more risk and potential reputational damage. The future belongs to teams that see governance not as a constraint, but as a catalyst for responsible innovation.

A strong CI/CD foundation is key to ensuring you can reap the benefits of AI and create high-quality user experiences at breakneck speed.
June 20, 2025
Code Signing in the DevOps Era: Silver Bullet or Security Theater?

In my work with global enterprises modernizing their DevSecOps practices, I’ve repeatedly seen a troubling pattern: Organizations implement code signing with good intentions, but without the controls to support it.

In one recent engagement, a team proudly showcased their secure pipeline – automated builds, signed containers and rapid deployments. But during a code audit, we found a private signing key embedded in a script, committed to version control, with no rotation or monitoring. That key had been used to sign production artifacts. If it had been compromised and we couldn’t be sure it hadn’t – an attacker could have shipped malicious code, fully “trusted” by their infrastructure.

This isn’t rare. Code signing is often deployed as a checkbox, not as part of a robust trust framework. And that creates a dangerous illusion of security.

Signed ≠ Safe: The Hidden Risks Behind the Signature

Digital signatures offer authenticity, not invincibility. Several high-profile attacks, including the SolarWinds breach and the more recent XZ Utils incident, show that attackers don’t need to bypass code signing; they just need to operate within its blind spots.

In the case of XZ Utils, malicious code was introduced over time and eventually signed and distributed legitimately. And in SolarWinds, attackers compromised the build system itself. The code was signed, but that didn’t stop the threat. These incidents make it clear that code signing doesn’t prevent compromise; it merely authenticates it.

Failures often stem from poor key management, inadequate revocation mechanisms, or an uncritical acceptance of signatures without examining the broader context. If your systems automatically trust any signed artifact without checking its provenance, you’ve already lost.

Speed vs. Safety: Why Code Signing Struggles in the DevOps Pipeline

In high-velocity environments, security controls are only effective if they blend seamlessly with development workflows. This is where code signing often stumbles. Signing keys may be embedded in scripts, mismanaged in cloud environments, or shared across teams. Developers, under pressure to release quickly, might bypass signing altogether if the process becomes cumbersome.

Worse, many CI/CD systems lack observability, making it difficult to detect anomalous signing behavior. In an era where pipelines are as critical as the code they deliver, this blind spot becomes a liability.

What Code Signing Actually Delivers—and Where It Falls Short

Despite its limitations, code signing still plays a vital role when treated as one part of a broader software security strategy. It must be tightly integrated with secure key storage, revocation processes and post-deployment monitoring. But that’s not enough.

Security leaders must look beyond signatures. Knowing who wrote the code and how it was built matters as much as the fact that it was signed. This means incorporating Software Bill of Materials (SBOMs), establishing build attestation and tracking dependencies in real time. It also means verifying that the code came from a trusted workflow, not just a trusted key.

Ultimately, security doesn’t stop at the signature — it begins there.

What CISOs Should Prioritize: From Signing to Sustained Trust

Code signing only works as part of a disciplined, layered security model. For CISOs and DevSecOps leaders, the challenge is not merely to introduce code signing into the pipeline but to operationalize it securely and sustainably. That means building a trust framework that spans people, process and platform.

Start with secure key management. Signing keys must be protected with the same rigor as encryption keys or credentials. This means hardware security modules (HSMs), cloud-native key vaults and enforcing granular access control — only authorized systems or identities should be able to sign code, and every usage should be logged.

Next, treat signing as a programmable policy, not an optional step. Integrate automated signing into CI/CD pipelines, using policy-as-code tools that enforce when, where and how signing occurs. All build artifacts should pass through this gate, and any deviation should be flagged for review.

Don’t stop at the signature. Ensure full provenance validation — know what was built, by whom, using which dependencies. Tools like in-toto, SLSA and SBOM generation solutions can help ensure that signatures are tied to a complete, verifiable chain of custody.

Adopt short-lived certificates and revocation mechanisms to reduce the blast radius. If a key is compromised or misused, organizations must be able to respond immediately by revoking trust and rotating credentials.

Crucially, invest in developer enablement. Developers are not cryptographers — and they shouldn’t have to be. Provide simple tooling, templates and education that make secure signing easy and error-resistant.

Finally, implement monitoring and anomaly detection for signing activities. Unusual signing behavior — like signing from an unexpected IP, service, or pipeline — should be treated as a potential breach and escalated accordingly.

These actions form a framework that moves code signing from a check-the-box task to a pillar of software trustworthiness.

The Checkbox Trap: Why Signatures Alone Aren’t Enough

A worrying trend is the “checkbox” mentality that surrounds code signing. Yes, your software is signed. But is it secure? Compliance might require a signature, but true assurance comes from layered validation, runtime introspection and knowing exactly what’s running in production.

As organizations strive to harden their software pipelines, it’s tempting to overvalue cryptographic proof. But trust is not binary. It’s dynamic. It must be earned and reaffirmed at every stage of the development and deployment lifecycle.

Conclusion: Trust, But Verify – and Then Monitor

Code signing, like many security tools, is powerful in theory and dangerous in isolation. It offers trust, but only to the extent that the surrounding processes are trustworthy. In the fast-moving world of DevOps, where builds, packages and deployments happen at breakneck speed, the biggest threat isn’t unsigned code – it’s unquestioned trust.

Security leaders must treat code signing as a control point, not a finish line. Don’t just ask, “Is it signed?” Ask, “Is it signed, tracked, validated and safe to run now and tomorrow?”

Trust begins at the signature. But in modern security, it never ends there.

June 9, 2025
Zero-Trust, Full Stack: Embedding Cybersecurity Principles Into Site Reliability Engineering Culture

These days, with digital threats everywhere, cybersecurity must evolve beyond just being a perimeter measure. Given the rapid delivery of software and the transient nature of infrastructure, security must be built into DevOps. This shift presents both a challenge and an opportunity for site reliability engineers (SREs) to apply zero-trust principles everywhere, starting with infrastructure and services and extending to how developers operate.

Zero-Trust: Beyond the Buzzword

While zero-trust is often associated with network security, many people do not realize it encompasses much more. It involves rethinking how trust is managed in distributed computing. The key idea is to always verify a person’s identity, device status and intent before granting access to any system element — regardless of its location on the network. The principle is ‘never trust, always verify’. Although this concept is used in security, it is still not fully practiced in SRE, as prioritizing availability and performance has usually been more important than focusing on security and telemetry.

With their expertise in systems and automation, SREs have the skills to take zero-trust beyond firewalls and identity solutions (refer to Figure 1). Testing these principles in reliability goals increases teams’ power to reduce the blast radius, secure production environments and deal with incidents more effectively.

Figure 1: High-Level Zero-Trust System.

It includes regular risk assessment with the help of a central analytics engine. Access to data is prevented by default and is granted only after proper verification. After users have been granted access, they can carry out transactions according to the determined risks. It constantly updates its decisions using information from various sources, such as identity, access context, security alerts and the ongoing session’s information.

The Convergence of Reliability and Security

Reliability engineering today focuses on more than just preventing downtime. The challenge is managing complexity and risk with continuous deployment, increasing service meshes and expanding application programming interface (API) surfaces. Changes in how production environments are run typically outpace traditional information system security (InfoSec) boundaries.

SREs fill this space by working with security teams and ensuring that security as well as observability are integrated into development pipelines. In other words, it is ‘security as dependability’ — they ensure there are no unauthorized changes, remove old passwords and ensure that staff have enough access to sensitive systems.

Take, for example, the consequences of using a compromised API token. If zero-trust principles — including strict access rules, regular authentication and control over service identities — are not applied, someone could use that token to move from microservice to microservice. By adopting zero-trust, SRE teams must integrate authentication between services, trusted connections using transport layer security (TLS) and policy checks directly into their workflow.

Policy as Code: Scaling Trust in the Pipeline

One crucial factor supporting zero-trust in SRE is policy as code. Just like infrastructure as code simplifies system creation, policy as code offers a way to automatically set and keep security policies up to date. Enforcing policies dynamically during continuous integration and continuous deployment (CI/CD) steps allows teams to enhance security while continuing at the same speed. SREs should understand policies as helpful guardrails that help maintain secure and proper configuration, access and deployment. Having policies managed and checked like other code enables a team to grow and creates trust among everyone working remotely.

Telemetry, Observability and Security Context

The nervous system of SRE is telemetry. Thanks to logs, metrics and traces, observability platforms help teams spot out-of-the-ordinary events, anticipate problems and understand the cause of any issues. Security signals such as unsuccessful logins, suspicious ways of gaining access and domain name system (DNS) tunneling are often supervised by different security operations center (SOC) teams.

Making cybersecurity part of SRE culture involves having telemetry that supports security observability, bringing security-related events into the same observability systems as those for performance and reliability. A centralized view reduces the time to locate the issue and improves how incidents are handled as a team. In a zero-trust model, each deviation from normal is considered a possible security threat.

Operationalizing Zero-Trust: Practical Steps for SRE Teams

Building a zero-trust culture in SRE does not require organizations to change everything at once. They can start embedding these practices in everyday operations by doing the following:

Enforce Identity Everywhere: Use evanescent keys, workload identity and service mesh for mutual authentication.

Audit by Default: All system changes, attempts to access them and incidents of policy breaches should result in structured logs that both the SRE and security teams have access to.

Integrate Policy Engines: During CI/CD, implement policies to confirm that deployments meet security and setup rules.

Minimize Human Access: Use automation and ephemeral credentials to eliminate shell access or long-lived keys.

Simulate and Test: Treat security risks as another factor that could cause a failure. Using chaos engineering principles, you can simulate attacks and test how to respond to them.

We must remember that the central aspect of zero-trust in SRE is changing the team’s approach to cybersecurity, not only replacing tools. SREs should learn to consider security events as they would other threats to the system’s reliability. In case of an incident, a security-related view should be included in the postmortem, and blameless retrospectives should focus on breaches of trust boundaries. By tying zero-trust with the pursuit of site reliability, groups can create an environment where security is everyone’s responsibility instead of being kept apart. By following these steps, SREs will ensure the systems remain up, running and safe.

June 9, 2025
Redgate Extends Effort to Integrate Database Management and DevOps Workflows

Redgate has updated its Flyway platform for applying DevOps workflows to database platforms to now provide deeper integration into command line interface (CLI) tools and integrated developer environments (IDEs).

In addition, the Flyway platform now enables state-based deployments using scripts that can be generated based on a specific schema.

Finally, Redgate is also adding options that enable DevOps teams to choose whether they want to include backups as baselines, automate the backup process altogether or never allow any type of shadow database.

Max Drobot, group product manager at Redgate, said these latest additions are intended to make it simpler for software engineering teams with varying levels of maturity to start automating the management of databases within the context of a DevOps workflow. Rather than trying to create the perfect process, it’s now simpler for DevOps teams to more easily experiment with automating database deployments without increasing risks, he added.

While DevOps engineers and database administrators (DBA) often need to work closely with one another, each of these teams has historically developed a separate culture around different classes of tools. Since it first launched Flyway, Redgate has been making a case for a platform that helps narrow that divide by enabling DevOps engineers to, for example, spin up a database when needed versus waiting for a DBA to have the time that would otherwise be required.

That approach doesn’t eliminate the need for a DBA, but it does serve to reduce the overall level of friction that often exists between DevOps teams and DBAs, noted Drobot.

The need to reduce that friction will become that much more pressing as the amount of data that needs to be incorporated into the next generation of artificial intelligence (AI) applications continues to exponentially increase, he added.

Additionally, DevOps teams as part of building and deploying more secure applications will also eventually need to programmatically apply policies and guardrails to the data being accessed by their applications, noted Drobot.

Managing databases has, of course, become more challenging as the number and types of them has steadily increased. Provisioning and managing databases using legacy manual processes is simply no longer tenable, he said.

Many organizations are already embracing platform engineering as a methodology for managing DevOps workflows at scale, so it’s now more a question of when database operations will become more centrally managed within the context of a software development lifecycle (SDLC).

In the meantime, DevOps teams might want to review how application developers are selecting databases for building applications today. All too often, rather than adhering to corporate standards, those decisions are based more on personal preference. In fact, it’s not uncommon for IT teams to find themselves spending time migrating an application developed on one database to another that the organization actually supports.

Each organization will, of course, need to decide on its own to converge the management of DevOps and database operations but given the pace at which modern applications are now being developed and updated in the age of AI, the amount of pressure being applied to achieve that goal is only going to continue to increase.

May 30, 2025
DevOps: More Than a Buzzword—A Mindset of Continuous Evolution
In recent years, the term DevOps has become one of the most talked-about buzzwords in the technology world. You’ll hear it in boardroom discussions, IT conferences, job postings, and even startup meetups. Companies want to “go DevOps,” developers want to work in DevOps environments, and recruiters are constantly looking for DevOps Engineers. But despite all this hype, DevOps is often misunderstood. Many think it’s a tool or a new kind of job title. In reality, DevOps is not a technology—it’s a mindset.

This article explains what DevOps really means, why it’s important, and how it embodies a cycle of continuous practices—like continuous integration, continuous deployment, continuous testing, continuous monitoring, continuous security, continuous improvement, and continuous feedback. We’ll explore these concepts in simple language and explain how they align with business strategy and team collaboration.

What Is DevOps, Really?

DevOps stands for Development and Operations. It brings together software developers (who write the code) and operations teams (who deploy and manage the code in production). Traditionally, these two teams worked separately. Developers would build software and hand it over to operations to release. This handoff model caused delays, confusion, and sometimes even system failures.

DevOps aims to break down these silos. It promotes collaboration, shared responsibility, and faster delivery of high-quality software. DevOps is not a product you can buy or a process you can install. It’s a cultural shift—a new way of thinking about how teams work together to deliver value to customers.

Why DevOps Is a Mindset, Not Just a Tool

Many companies start their DevOps journey by adopting tools like Jenkins, Docker, Kubernetes or Terraform. While these tools help automate tasks, they don’t make an organization “DevOps-ready” by themselves. A DevOps culture is built on principles such as:
- Shared goals between development, operations, and business teams
- End-to-end accountability for software quality and performance
- Fast, safe, and frequent delivery of new features
- Embracing failure as a learning opportunity
- Continuous improvement and feedback
These principles require changes in how people work, how they communicate, and how they measure success. In other words, DevOps is a people-first approach, supported by tools—not the other way around.

Strategic Alignment: Connecting DevOps to Business Goals

One of the biggest benefits of DevOps is its ability to align IT efforts with business goals. When development and operations teams work closely with product managers and business leaders, they can prioritize features that deliver real value to customers.

For example, instead of spending months developing features that may never be used, a DevOps team can release small updates frequently, gather user feedback, and adjust the roadmap. This approach supports agile decision-making, reduces risk, and increases customer satisfaction.

DevOps also emphasizes metrics that matter to the business, such as:
- Deployment frequency
- Lead time for changes
- Mean time to recovery (MTTR)
- Customer feedback and satisfaction
These metrics help teams measure their performance and make data-driven decisions.

The Pillars of DevOps: A Culture of Continuity

DevOps is powered by a series of continuous practices. Let’s walk through each one and understand how they fit together.

1. Continuous Integration (CI)

Continuous Integration is the practice of automatically merging code changes into a shared repository several times a day. Every time a developer writes new code, it is tested and integrated with the existing codebase. This helps catch bugs early and ensures the software always stays in a working state.

Key benefits:
- Faster development cycles
- Reduced integration issues
- Early bug detection
CI tools: Jenkins, GitLab CI, CircleCI, Travis CI

2. Continuous Deployment (CD)

Once the code passes all the tests, it is automatically deployed to production or staging environments. This is known as Continuous Deployment. It removes manual intervention and allows teams to release features to users quickly and reliably.

Key benefits:
- Shorter release cycles
- Faster feedback from users
- Reduced manual errors
CD tools: Spinnaker, Argo CD, AWS CodePipeline

3. Continuous Testing

Continuous Testing ensures that the software is tested at every stage of the development lifecycle. This includes unit tests, integration tests, performance tests, and even security tests. Automated testing tools help identify defects early and prevent bugs from reaching the end user.

Key benefits:
- Improved quality
- Faster bug detection
- Increased confidence in releases
Testing tools: Selenium, JUnit, TestNG, Postman, SonarQube

4. Continuous Monitoring

After the software is released, it’s important to monitor its performance, availability and user behavior in real time. Continuous Monitoring helps detect issues early, prevent downtime, and understand how users interact with the application.

Monitoring also provides telemetry data, which can be used to improve future versions of the product.

Key benefits:
- Better uptime
- Real-time alerts
- Insights into user experience
Monitoring tools: Prometheus, Grafana, Datadog, New Relic, ELK Stack

5. Continuous Security (DevSecOps)

In the past, security was often added at the end of the development process. In DevOps, security is integrated from the beginning. This practice is called DevSecOps—short for Development, Security, and Operations.

Security checks are built into the CI/CD pipeline, and developers are trained to write secure code. Automated tools scan for vulnerabilities in real time.

Key benefits:
- Early detection of security flaws
- Lower risk of breaches
- Compliance with security standards
Security tools: Snyk, Aqua, Clair, Fortify

6. Continuous Feedback

Continuous Feedback means collecting real-time input from customers, end-users, and stakeholders. This feedback is then used to improve the product in the next cycle. It could come in the form of bug reports, customer reviews, surveys, or usage analytics.

Feedback is also encouraged within teams. Retrospectives, peer reviews, and performance metrics help teams learn and grow continuously.

Key benefits:
- Better user experience
- Product features that match real needs
- Faster response to change
Feedback tools: Jira, Slack, UserVoice, Microsoft Teams

7. Continuous Improvement

DevOps teams strive to improve with every sprint, release, and incident. This involves reviewing past performance, identifying bottlenecks, and experimenting with new ideas.

Key aspects include:
- Regular retrospectives
- Automation of manual tasks
- Process optimization
- Team learning and training
Continuous improvement is what turns a good DevOps team into a great one.

Benefits of a DevOps Mindset

Organizations that adopt a true DevOps mindset report several business and technical benefits:
1. Faster Time to Market
  Teams can deliver features, updates, and fixes faster and more frequently.
2. Better Collaboration
  DevOps breaks down silos, encouraging communication and shared responsibility.
3. Higher Quality and Reliability
  Frequent testing and monitoring improve the quality of software.
4. Stronger Security
  Security is integrated into every step, reducing risks and vulnerabilities.
5. Improved Customer Satisfaction
  Faster updates and quicker fixes enhance the customer experience.
6. Happier Teams
  Empowered teams that can deploy safely and frequently feel more motivated.
Challenges in Adopting DevOps

Adopting DevOps isn’t always easy. Some of the common challenges include:
- Cultural resistance: Changing mindsets takes time.
- Legacy systems: Old infrastructure may not support automation.
- Tool overload: Choosing and integrating the right tools can be complex.
- Lack of skills: Teams may need training in automation, cloud, and testing.
- Fragmented processes: Without a unified strategy, DevOps can become chaotic.
The key is to start small, show quick wins, and scale gradually.

DevOps Success Stories

Many companies have transformed their development culture through DevOps:
- Amazon deploys code thousands of times a day using DevOps automation.
- Netflix built its world-class streaming platform on DevOps principles.
- Etsy recovered from deployment issues by investing in a DevOps culture.
- Toyota (where I’ve had the honor to lead) leverages DevOps to enhance reliability, performance, and cost-efficiency in enterprise data platforms.
Final Thoughts: DevOps Is a Journey

DevOps is not a one-time project—it’s a journey of continuous transformation. It’s about creating a culture where development, operations, business, and security teams work together with shared goals, automated processes, and customer-centric thinking.

Yes, the tools matter. But more important is the mindset. When teams truly embrace DevOps, they move from delivering code to delivering value—faster, safer, and with greater impact.

So next time someone calls DevOps a “buzzword,” remember this: it’s not a trend, it’s a transformative philosophy—one that’s changing how the world builds and delivers technology.
May 29, 2025