DEV Community: CloudBees

Build a cloud native CI/CD workflow in 2 mins - yes, really!

CloudBees — Wed, 12 Jun 2024 19:01:53 +0000

CloudBees platform is your sandbox for innovation.

We want to empower every developer to embark on something innovative as quickly as possible. Our testament to this obsession starts with how easy it is to create a truly cloud native CI/CD workflow with our platform - create and execute a build, scan, and deploy workflow within 2 minutes!

Here’s how.

STEP 1- Set up your initial credentials

Start at cloudbees.io. You have multiple ways to sign up - ex: using your GitHub and Google accounts - to streamline the process. We’ll use the example of signing up via email here. Enter your email address and password. Verify your email following that.

STEP 2 - Install your GitHub app

You’re now officially signed into your account! Choose your pathway: Run a sample workflow or CI insights for Jenkins. Choose the first path (‘Run a sample workflow’) for this scenario. Select GitHub as your provider. Install the GitHub app and connect the repository, which will form the basis for your workflow.

STEP 3 - Create the component in the platform

You’re in! Name the component based on your loaded repository and click ‘Create Component.’

STEP 4 - Explore the carousel on what you can do

You will see a workflow composer in a few seconds after clicking ‘Create Component.’ During this time, you can browse a carousel of what you can do with workflows and the platform.

STEP 5 - Click ‘Create Sample Workflow’

Finally, click ‘Create Sample Workflow’ to land on the workflow composer. It includes a visual workflow orchestration tool that makes creating and managing complex software delivery pipelines easy.

Here, the platform detects a Java project and automatically updates it to reveal a Java template workflow.

And there you have it! A cloud native CI/CD workflow ready for your use. You can commit it or modify it any way you want.

Platform Update: Fresh Look, New Features, and a Price Drop!

Here’s a quick update on what we’ve been working on lately:

Released Feature Management 1.0 for the major progressive delivery use cases
Added new usability and insight upgrades for our popular analytics reports
Streamlined the journey to your first workflow with immediate insights

And that’s just the beginning! With all these cool enhancements, we're also slashing our Team pricing big time – from $100/month to just $30/month.

What do you get when you upgrade from the Free version?

8,000 additional workflow execution minutes
Unlimited sub-organizations
12 months log retention
Essentials Support

Enjoy the features you love and get even more for what you pay.

TRY the CloudBess platform today ✅

New Feature Update: Dynamic Time Calculations in Analytics Reports

CloudBees — Fri, 31 May 2024 15:14:38 +0000

We continue to tweak our popular analytics reports to improve usability and the ease of generating insights. The latest in this effort is Dynamic Time Calculations - this update lets every user view these reports specific to their location and time analysis needs.

Below is a sprinkling of ways to take advantage of this feature update.

Personalize your time zone

Your time zone is set automatically in your profile as a new user - this means you interpret all the insights on your analytics reports specific to your time zone.

Let’s look at an example from the ‘Software delivery activity’ report. In the snapshot below, the commits trend chart shows the numbers specific to the Eastern Time Zone: 13,356 total commits from May 1st to May 31st, 2024. The same chart in a different time zone can yield a different result depending on the start of the May 1st count.

Users now have the option to overwrite the automatic time zone setting through their profile. Click on ‘User Profile’ under your name to head to a secondary screen.

On the secondary screen, uncheck the ‘Set time zone automatically’ box and pick your preferred time zone.

Use pre-defined time filters…

When you click the filter button, three new pre-defined time filters appear - Last 7 days, Last 30 days, and Last 90 days. These time filters let you aggregate and get a good measure of daily, weekly, and monthly activity on a rolling basis.

...Or set your own time filters

If the pre-defined time filters don't suit your analysis needs, choose ‘Custom range’ to pick a start and end date.

All these options are available across each of the 5 analytics reports. If you have any questions, contact us via Slack or email our support team. And if you haven’t seen the platform in action yet…

Try the CloudBees Platform for FREE today!

New Feature Update: Compare metrics across sub-orgs and components

CloudBees — Mon, 20 May 2024 14:20:27 +0000

One of our well-received platform features is the range of analytics reports offering insights for a deep dive into engineering efficiency, risk mitigation, and quality assurance.

We continue to optimize these reports not only for insights but also for overall usability. Our latest update for these reports is your ability to gather and contrast insights across sub-orgs and components.

Let’s lean on a real-world use case to take a closer look.

Assume you’re an engineering director. As part of your multiple mandates, you have to uncover where your engineering team spends their time and whether it aligns with business objectives. It’s the classic case of allocating your resources to high-value projects.

One way to do this is to look at your entire organization’s commits and pull requests in the software delivery report. Check out the snapshot below for starters.

You can click the highlighted icon (available on almost every widget) to slice down the pull requests further. The icon opens a drawer to the right to show the pull requests by sub-orgs and components. Drill deeper by looking at the breakdown across multiple sub-org layers. Sort the list by clicking the table header in the drawer.

A key point to remember is that any breakdown depends on which org/sub-org/sub-sub-org (for ex) you select.

In the above example, ~62% of the pull requests (557 out of 903) relate to the ‘reports-service’ component. This serves as a checkpoint on whether you should reallocate your resources as an engineering director. It’s particularly problematic if ‘reports-service’ is not a business priority.

Again, this is one way to use this feature update for every single widget across the different analytics reports. Stay tuned for more updates and new feature releases in the next few weeks. In the meantime…

Try the CloudBees Platform for FREE today!

DevSecOps Made Easy (Pt 2) - Stay clear of any lock-in

CloudBees — Thu, 16 May 2024 20:34:32 +0000

The Sad Status Quo

You must be prudent about what you’re signing up for with a DevSecOps vendor. There are so many clever ways they can lock you into an undesirable situation. Check out a few examples below.

Some limit your flexibility to move your SCM, CI/CD pipelines (for ex) when your requirements change.
They can offer a CI/CD solution as a free add-on to a separate multi-year licensing agreement. And then force you to pay after you’re well embedded into their CI/CD solution.
You’re dealing with a sudden increase in your annual DevSecOps subscription price because you decided to use their competitor’s cloud infrastructure.
You have to learn a specific DSL to configure pipelines, even though every developer within your company finds it hard to understand.
You must modify your internal processes since their DevSecOps offering can’t meet you where you are right now.
You suddenly have to rewrite your infrastructure code in their terms; otherwise, their solution doesn’t work.

This list continues to grow!

How CloudBees Makes DevSecOps Easy

We meet you where you are. We proceed the way you prefer.

What does this mean in less marketing terms? A multitude of things, but here’s a snapshot.

CloudBees can help you transition to cloud native at your own pace. You can start greenfield projects in a cloud native environment while still retaining your older infrastructure. For example, you can run both Tekton-based workflows and Jenkins pipelines in parallel within the same platform.

Your developers can continue to use the tools they know or even choose the best-of-breed tools they need for your complex environments. You’re not stuck using lightweight tool replacements. CloudBees offers multiple opportunities to integrate.

We make it easy for you to integrate legacy systems and customize projects at scale. You don’t have to deal with the inability of some vendors to integrate or adopt internal processes.

Start using the CloudBees platform for FREE today and find out for yourself!

DevSecOps Made Easy (Pt 1) - Choose the tool you prefer

CloudBees — Fri, 10 May 2024 19:40:05 +0000

The Sad Status Quo

Many of the DevSecOps vendors suffer from a mix or all of the following ailments,

They won't let you fully use your existing best-of-breed tools.
They offer no support for integrations or limited opportunities to integrate.
They make it hard to customize projects at scale.
They’re deliberately challenging when it comes time to integrate any legacy system.
They leave you with recurring integration issues when they oblige and integrate.
They don’t adopt internal company processes effectively.

And the list grows…

How CloudBees Makes DevSecOps Easy

The CloudBees platform uses an open and integrated architecture based around popular open standards and de-facto open-source cloud-native technologies such as Kubernetes, Tekton, OpenSearch, OAuth, OpenFeature, and Keycloak. The platform is fully extensible and easily integrated with popular DevSecOps tools.

Choose the tool you prefer for the job, easily plug it in, turn it into an action, and execute anywhere you choose - avoid hassles with instability, technical complexity, and a ‘forced’ toolset.

Start using the CloudBees platform for FREE today!

Cloud Transformation: A Roadmap for the Future

CloudBees — Tue, 23 Apr 2024 21:46:45 +0000

As organizations strive to remain competitive in the digital age, cloud transformation has emerged as a pivotal strategy. This journey involves more than just shifting resources to the cloud; it encompasses a comprehensive reevaluation of how businesses deploy, manage, and leverage technology to drive growth and innovation. Drawing on CloudBees' expertise and industry best practices, this blog outlines a roadmap for successful cloud transformation.

Phase 1: Assessment and Planning

Before embarking on a cloud transformation journey, it's crucial to assess your organization's readiness and define clear objectives.

Strategy: Conduct a Thorough Assessment

Begin by evaluating your current infrastructure, applications, and workflows. Identify which areas will benefit most from cloud adoption and align your cloud strategy with your overall business goals. Consider factors such as:

Application complexity and dependencies
Data security and compliance requirements
Performance and scalability needs
Cost optimization opportunities

Phase 2: Migration and Implementation

With a solid plan in place, the next step is to start the actual migration to the cloud. This phase can be complex and challenging, involving the transfer of data, applications, and services.

Strategy: Adopt a Phased Approach

Adopt a phased approach to migration, prioritizing applications and workloads based on their complexity and business impact. Consider the following steps:

Identify and prioritize applications for migration
Develop a migration plan and timeline
Execute the migration using appropriate tools and strategies
Validate and test migrated applications

Utilize CloudBees solutions to manage and automate aspects of the migration process, minimizing downtime and ensuring continuity of operations.

Phase 3: Optimization and Scaling

Once your assets are in the cloud, the focus shifts to optimization. This involves fine-tuning resources to ensure cost-efficiency, performance, and security.

Strategy: Continuous Optimization

Leverage cloud-native tools and services to monitor usage, automate scaling, and enhance security. CloudBees offers analytics and optimization tools that provide insights into cloud resource utilization, helping you maximize the value of your cloud investments. Key areas to focus on include:

Right-sizing resources based on actual usage
Implementing auto-scaling policies
Monitoring and optimizing costs
Enhancing security through encryption, access controls, and compliance measures

Phase 4: Innovation and Evolution

The ultimate goal of cloud transformation is not just to replicate existing services in the cloud but to unlock new opportunities for innovation and growth.

Strategy: Foster a Culture of Innovation

Encourage experimentation and leverage the cloud's agility to test new ideas quickly. CloudBees supports this innovative mindset through its flexible, scalable platform, enabling teams to rapidly develop, deploy, and iterate on applications. Consider the following approaches:

Adopt agile development methodologies
Implement continuous integration and continuous deployment (CI/CD) pipelines
Leverage cloud-native services for machine learning, IoT, and serverless computing
Foster a culture of collaboration and knowledge-sharing

Navigating Challenges

The road to cloud transformation is fraught with challenges, from technical hurdles to cultural resistance.

Strategy: Address Challenges Head-on

Ensure clear communication, provide training and support to your teams, and partner with a trusted provider like CloudBees. Our comprehensive suite of tools and services can help overcome the common obstacles associated with cloud transformation, such as:

Data security and compliance concerns
Skills gaps and expertise shortages
Integration with existing systems and processes
Governance and cost management

By addressing these challenges proactively and leveraging CloudBees' expertise, organizations can mitigate risks and ensure a smoother transition to the cloud.

Measuring Success

To gauge the effectiveness of your cloud transformation efforts, it's essential to establish metrics and KPIs that track progress and demonstrate value. Some key metrics to consider include:

Cost savings and optimization
Application performance and availability
Time-to-market for new features and services
User adoption and satisfaction
Security and compliance posture

By regularly measuring and reporting on these metrics, organizations can showcase the tangible benefits of their cloud transformation initiatives and justify further investments.

Summary

Cloud transformation is a journey that requires careful planning, execution, and ongoing management. Organizations can successfully navigate this transition by following a structured roadmap and leveraging the right tools and strategies. CloudBees stands ready to assist, providing the expertise, solutions, and support needed to harness the full potential of the cloud.

Take the first step in your cloud transformation journey today. Contact CloudBees and discover how our suite of tools and services can help you achieve your goals. With CloudBees as your partner, you can confidently navigate the path to cloud transformation and unlock new opportunities for innovation and growth.

How to build a resilient DevOps culture in times of change

CloudBees — Tue, 16 Apr 2024 16:47:18 +0000

The software development world changes so fast that embracing DevOps becomes even more critical to maintaining speed, efficiency, and innovation. Success with DevOps is a lot bigger than a simple implementation of tools or processes. You have to foster the right culture.

In this post, we'll explore strategies to build that resiliency in your DevOps culture that enables your organization to survive the constant waves of change.

What does RESILIENCE mean in DevOps?

Resilience in DevOps is the ability of a team to adapt, recover, and continuously improve amidst varying challenges. To create an environment where you encourage failures and adaptability is part of the team's ethos.

A few strategies to cultivate RESILIENCE…

#1 - Embrace change as a constant

The first step in building a resilient culture is acknowledging that change is inevitable. Teams should prepare to anticipate and embrace change and not simply react to it.

For instance, Spotify encourages autonomous squads to experiment and adapt quickly to foster a culture that thrives on change. Conduct training sessions, workshops, and cross-functional team interactions to expose team members to different perspectives and skills.

#2 - Foster a blameless culture

A blameless culture is one where team members can discuss mistakes openly and feel safe without fear of retribution. Etsy's blameless postmortems are a great example of this in action. Focus on the lessons learned instead of pointing fingers. Teams can understand what went wrong and prevent similar issues in the future. Leaders should also model vulnerability, encourage open dialogue, and emphasize learning over punishment.

#3 - Encourage continuous learning and improvement

DevOps is as much about continuous improvement as it is about continuous delivery and integration. Take Google's "20% time" policy - a prime example of how the company prioritizes continuous learning by enabling employees to dedicate a portion of their work hours to learning and experimentation.
Encourage teams to set aside time to explore new technologies, techniques, and methodologies to stay ahead of the curve and constantly grow. Leaders can provide resources, recognize learning efforts, and create knowledge-sharing spaces.

#4 - Promote psychological safety

Psychological safety is the belief that you can speak up with ideas, questions, concerns, or mistakes without punishment or humiliation. It's the foundation of a resilient DevOps culture. Leaders can promote psychological safety by actively listening, showing empathy, and acknowledging the contributions of all team members.

Establish clear guidelines for respectful communication and conflict resolution to reinforce a psychologically safe environment. Building trust is a continuous process that requires consistent effort and commitment.

#5 - Implement effective communication channels

A fast-paced DevOps environment requires clear and transparent communication. Implement effective communication channels in tools like Slack and hold regular stand-ups or check-ins to align everyone with the team's goals, roles, and responsibilities. This is especially important during periods of change when uncertainty can lead to confusion and misalignment. When selecting communication tools, consider the team's preferences and workflow to ensure seamless adoption and usage.

#6 - Empower team members

Empowerment is about giving team members the autonomy to make decisions and take action. Amazon's "two-pizza teams" - i.e., teams small enough to be fed by two pizzas - exemplify how smaller, empowered teams can drive innovation and adapt quickly.

Trust teams to determine the best path forward by providing clear goals and guidelines. Leaders can foster a sense of ownership and accountability, drive individuals to perform at their best, and adapt more readily to changes. Regularly solicit feedback and ideas from team members to reinforce their sense of empowerment and contribution to the team's success.

You will have to navigate challenges.

Building a resilient DevOps culture comes with challenges. One common obstacle is resistance to change, particularly from team members accustomed to traditional working methods. To address this, leaders should communicate the benefits of change clearly, involve team members in the change process, and provide support and resources to help them adapt.

Another challenge is preventing burnout in a fast-paced, constantly evolving environment. Encourage work-life balance, set realistic expectations, and provide mental health resources to mitigate this risk.

How to measure success

Define and track relevant metrics to build a resilient DevOps culture effectively. These could include team velocity, time to recover from failures, employee satisfaction scores, and the frequency of learning opportunities. By regularly assessing these metrics and gathering feedback from team members, organizations can identify areas for improvement and celebrate successes along the way.

Parting thoughts…

Building a resilient DevOps culture is a journey, not a destination. It requires commitment, leadership, and continuous effort from all levels of the organization.

As you navigate through times of change, remember that the strength of DevOps lies not just in its tools and processes but in the resilience of its people and culture. Let's nurture these human elements to build a genuinely resilient DevOps environment. Assess your current culture, identify areas for improvement, and engage your team in open discussions about how to foster resilience. Small steps, consistently taken, can lead to significant transformations over time.

Resources to further explore for insights and practical advice

"The DevOps Handbook" by Gene Kim, Jez Humble, Patrick Debois, and John Willis
"Accelerate: The Science of Lean Software and DevOps" by Nicole Forsgren, Jez Humble, and Gene Kim

Remember, a resilient DevOps culture harnesses the winds of change to propel the organization forward. Embrace the journey, learn from the challenges, and watch your team thrive in the face of any obstacle that comes their way.

Progressive Delivery: A Detailed Overview

CloudBees — Mon, 08 Apr 2024 14:18:37 +0000

Every developer has been there before: You release a new feature expecting a smooth ride, only to have something go awry in the back end at the last minute.

An event like this can derail a launch, letting down customers and leaving you scratching your head wondering what went wrong.

Suffice it to say that software development is very complex, and small issues can easily sneak through into production without detection. To avoid this, many development teams are now changing their vetting strategy and testing more during production using the progressive delivery model.

Keep reading to learn the basics of progressive delivery and how it can help your company iterate with greater safety and efficiency—bringing more powerful products to market faster.

What is Progressive Delivery?

In a traditional waterfall model, teams release new features to an entire user base at one time. Using progressive delivery, you roll out features gradually.

Here’s how it works: DevOps managers first ship a new feature to release managers for internal testing. Once that’s done, the feature goes to a small batch of users to collect additional feedback, or is incrementally released to more users over time. The final step is a general launch when the feature is ready for the masses.

It’s a bit like dipping your toes into the water before diving in. If something goes wrong during a launch, you haven’t exposed your entire user base to it. You can easily roll the feature back if you need to and make changes.

The Evolution of Progressive Delivery

Progressive delivery emerged in response to widespread dissatisfaction with the continuous delivery model. DevOps teams needed a way to control software releases and catch issues early on instead of pumping out bug-filled versions to their users, and progressive delivery met this requirement.

The idea stems from Microsoft’s progressive experimentation concept, which involves studying the blast radius prior to a product launch to determine how it will affect users.

As the story goes, RedMonk co-founder James Governor took this concept and applied it to the continuous delivery model. Governor explains this in this compelling webinar on progressive delivery—a must-watch for anyone interested in learning more on the topic.

It’s important to note that progressive delivery doesn’t replace continuous delivery. Rather, progressive delivery enhances continuous delivery and helps companies do it more effectively.

What Are the Benefits of Progressive Delivery?

There are several reasons why your company may decide to move beyond continuous delivery and embrace a progressive strategy instead.

Improve Efficiency
As Governor explains in his primer, software development is shifting away from the idea of moving quickly and breaking things. Today, there’s growing interest in accelerating development pipelines—without breaking things.

Companies want to take ownership of their code and deliver high-quality software. By incorporating rigorous testing into the process, progressive delivery enables you to ship large volumes of code at a higher volume without having to worry about frustrating the user experience.

Deploy Selectively
Progressive delivery lets you deploy new features to select user groups. This way, you can iron out any bugs and gather feedback before a general launch.

Target Different Geographic Locations
People tend to use software differently depending on their geographical location. Customers in Japan may approach an application in a much different way than customers in the US, for example.

Developers need to take into consideration differing workflows, privacy restrictions, and language and cultural needs. Once again, progressive delivery helps here, too, by enabling you to discover needs and conflicts early on and make adjustments as you move forward.

Reduce User Pushback
In his overview of progressive delivery, Governor makes a great point that people generally don’t like it when applications change.

Google recognizes this, which is why the company lets users switch over to new features at their own pace, giving them time to process the change. This reduces pushback and also gives developers more time to collect feedback and make small improvements.

Ship Software Faster
With progressive delivery, you perform certain user tests during and after the launch. This ultimately saves time by enabling you to catch issues earlier. It prevents you from having to go back and make large structural changes deep in the production cycle.

Maintain Customer Trust
Progressive delivery protects the customer experience by reducing risk. If a small user group has trouble with an update or is overwhelmingly against it, you can figure out why and decide how to address the situation.

By taking this approach, you can build customer trust while shielding the majority of customers from the messy development process.

Free Developers to Focus on Innovation
One of the fundamental pillars of progressive development is progressive delegation. With this approach, a group of engineers first develops and tests a feature. After that, the software goes to a product manager, who conducts further testing and oversees the release.

This frees developers to spend more time focusing on building and testing new features instead of refining code for release. It keeps pipelines moving, ultimately enabling companies to churn out features at scale faster.

Testing tends to be dull, repetitive and time-consuming. Since talented developers want to spend their time creating and building, progressive delivery keeps teams engaged and reduces turnover.

Lower Development Costs
A progressive delivery model gives teams multiple opportunities to catch bugs and vulnerabilities before a full release. Since it’s generally much cheaper to make changes early on in the development cycle, this strategy can save a lot of money over time.

Supporting Elements for Progressive Delivery

Progressive delivery brings together many different software development methodologies.

Here’s a breakdown of some key enabling elements.

A/B Testing
A/B testing, or split testing, involves taking two versions of a piece of software and comparing how they perform.

For example, you might release an app with two different interfaces and see how users respond. After collecting feedback, you can move forward confidently with the app that generates stronger results.

Canary Testing
Canary testing originates from the phrase “canary in the coal mine,” wherein miners would use a live bird to test for toxic fumes.

With modern canary testing, you release code to a small group of users to see if it’s safe to release to a larger base. In this case, users act like canaries by testing the software.

Blue-Green Deployments
In a blue-green deployment, you set up two identical production environments: a blue and green one. One is live, and the other is for testing.

When it’s time to release a new software version, you swap the blue and green environments. This approach can reduce downtime and risk when rolling out a new service.

Continuous Delivery Release Orchestration (CDRO)
CDRO tools enable rapid application delivery and help deliver better quality software.

These tools introduce automation and monitoring throughout various stages of development, expediting testing and streamlining monitoring. With the right solution in place, you can manage your pipeline and environment more effectively while taking advantage of deployment automation and leveraging pipeline analytics to continuously refine your processes.

Observability
Observability is a control theory method for understanding a complex system. It involves using tools like logging, tracing and analytics engines to understand how services are performing and interacting.

Through observability, it’s possible to determine whether you need to release an update to a group of users. Pairing user analytics engines with feature flag management systems can also automate the rollout or rollback based on pre-specified user criteria.

Service Mesh
A service mesh is an infrastructure layer that sits over a container network interface (CNI) and contains a control plane and a data plane. Two popular examples include Istio and AWS App Mesh.

This type of solution can enable user segmentation, traffic shifting management, observability and automation—all of which play a crucial role in progressive delivery.

Feature Flags
Feature flags, or feature toggles, are an important operational mechanism for progressive delivery. Flags let you control various functions during runtime.

By deploying feature flags, you can turn features on and off for different groups of users. In this light, feature flags help control and limit deployments to select users.

Move Beyond Continuous Delivery With CloudBees

Thinking about implementing progressive delivery in your DevOps strategy?

It’s a bold leap. But it’s one that could have a profound impact on the way your company handles software releases. Through progressive delivery, your team can tighten its grip on software production, collect more user feedback and catch errors before they slip into production.

If you’re thinking about moving forward with progressive delivery, check out the CloudBees platform, which includes an advanced feature flagging mechanism that enables dev teams to target different users based on various attributes and manage who receives updates and when.

For more information on how you can use CloudBees Feature Management to accelerate your progressive delivery efforts and build a smoother production environment, check out the documentation.

Additional Resources

Read the eBook: 5 Things You Need to Get Started with Enterprise Progressive Delivery

CloudBees CI add-on for Amazon EKS blueprints

SamanthaF — Thu, 04 Apr 2024 07:00:00 +0000

Hey there! If you've dabbled with Amazon Elastic Kubernetes Service (Amazon EKS), you know it's a breeze to run add-ons developed by the Kubernetes open-source community. But, with so many tools and designs out there, crafting a custom Amazon EKS cluster to fit your app's needs might seem like a marathon.

Enter Amazon EKS blueprints – your new best friend for easily setting up EKS clusters packed with everything your software delivery team dreams of. These blueprints are like your recipe for success, using Infrastructure as Code (IaC) modules to serve up a ready-to-go Amazon EKS cluster for CloudBees CI, complete with all the essential tools to get those workloads running. And the cherry on top? You can deploy it across different accounts and regions in Amazon Web Services (AWS) without breaking a sweat.

Now, you might wonder, "Where does CloudBees CI fit into this picture?"

Well…..(puts on marketing hat)

1: CloudBees is thrilled to announce its integration into the expansive Amazon EKS blueprints community as an AWS partner add-on. This collaboration simplifies the adoption and exploration of CloudBees CI’s enterprise features through two key components:

The deployment of CloudBees CI on modern platforms in AWS EKS is streamlined into a singular Terraform module, making the onboarding process seamless and efficient.
A suite of blueprints for the CloudBees CI add-on module, designed for compatibility with Amazon EKS blueprints for Terraform that adhere to the EKS Best Practices Guides, ensuring optimized performance.

2: CloudBees CI is a super robust continuous integration (CI) tool built on Jenkins—you know, the go-to CI/CD orchestrator. It's perfect for big enterprises that love Jenkins but need more oomph in managing and scaling it. While there's a bunch to highlight, we're zeroing in on how CloudBees CI and Amazon EKS blueprints team up.

3: If you have played around with the new CloudBees platform, the Terraform module and its companion blueprints leverage the CloudBees platform for the blueprint CI builds. CloudBees platform actions orchestrated by workflows allow us to perform automated testing for each new release (refer to the .cloudbees folder) for more info.

(pause while i take off my marketing hat and put on my “make it so” hat)

Setting up your Amazon EKS cluster with CloudBees CI is now as easy as pie (mmmm pie), letting you focus on what really matters – delivering awesome software.

Let's get to the good stuff:

Blueprint 01: Getting Started
Get started with the CI on modern platforms in Amazon EKS by running this blueprint, which installs CloudBees CI on modern platforms and its prerequisites, to help you understand the minimum setup which includes:

AWS Certificate Manager (ACM)
Amazon EKS blueprints add-ons: AWS Load Balancer Controller ExternalDNS Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) driver, to allocate Amazon EBS volumes for hosting $JENKINS_HOME.

Blueprint 02: Deployment at Scale
Once you are familiar with CloudBees CI blueprint add-on: Getting started(Blueprint 01 from above), this blueprint presents a scalable architecture and configuration by adding:

An Amazon Elastic File System (Amazon EFS) drive that is required by CloudBees CI High Availability/Horizontal Scalability (HA/HS) controllers and is optional for non-HA/HS controllers.
An Amazon Simple Storage Service (Amazon S3) bucket to store assets from applications like CloudBees CI, Velero, and Fluent Bit.
Amazon EKS managed node groups for different workloads: CI applications, CI on-demand agents, CI spot agents, and Kubernetes applications.
Amazon CloudWatch Logs to explode control plane logs and Fluent Bit logs.
The following Amazon EKS blueprints add-ons:

   1. AWS EFS CSI Driver: Connects the Amazon EFS drive 
      to the Amazon EKS cluster
   2. AWS for Fluent Bit: Acts as an applications log 
      router for log observability in CloudWatch.
   3. Cluster Autoscaler: Watches Amazon EKS managed node 
      groups, to accomplish CloudBees CI auto-scaling 
      nodes on Amazon EKS.
   4. Kube Prometheus Stack: Used for metrics 
      observability.
   5. Metrics Server: This is a requirement for CloudBees 
      CI High Availability controllers for horizontal pod 
      autoscaling.
   6. Velero: Backs up and restores Kubernetes resources 
      and volume snapshots, which is only compatible with 
      Amazon EBS.

Cloudbees CI uses Configuration as Code (CasC)to enable exciting new features for streamlined DevOps and other enterprise features, such as CloudBees CI Hibernation
- The CI operations center is using the CasC Bundle Retriever.
- Managed controller configurations are managed from the operations center using source control management (SCM).
- The managed controllers are using CasC bundle inheritance (refer to the parent folder). This "parent" bundle is inherited by two types of "child" controller bundles: high availability (HA) and none-HA, to accommodate considerations about HA controllers.

Conclusion

There you have it! With Amazon EKS blueprints and CloudBees, you're essentially fast-tracking your projects. So, why not give it a shot and see how it can boost your projects? Trust me, it's worth exploring.

This is a summary repost from the blog: CloudBees CI add-on for Amazon EKS blueprints, which contains even more links and architectural diagrams of the infrastructure for your viewing enjoyment.

Feature Flags vs. Feature Management: A Technical Deep Dive for SREs

CloudBees — Mon, 01 Apr 2024 13:46:01 +0000

As Site Reliability Engineers (SREs), your primary mission is to ensure the reliability, stability, and performance of production systems. In the pursuit of this goal, you constantly seek out innovative approaches and technologies that can help mitigate risks, minimize downtime, and deliver value to users. Two such methodologies that have gained significant traction in the SRE community are feature flags and feature management.

In this blog post, we'll dive deep into the technical aspects of feature flags and feature management, exploring how they can be leveraged by SREs to enable progressive delivery, improve system resilience, and optimize the user experience. We'll discuss the implementation details, best practices, and challenges associated with these approaches, focusing on how they align with the specific roles, responsibilities, and priorities of SREs.

Feature Flags: A Granular Approach to Functionality Control

Feature flags, also known as feature toggles, are a powerful technique that allows SREs to control the activation and deactivation of specific application functionalities without modifying the codebase. At its core, a feature flag is a conditional statement that determines whether a particular feature should be executed based on predefined criteria. The most basic implementation of a feature flag in Go can be expressed as follows:

func main() {
    if isFeatureEnabled() {
        // Execute new feature code
    } else {
        // Fall back to existing functionality
    }
}

func isFeatureEnabled() bool {
    // Logic to determine if the feature is enabled
    // This can be based on configuration, environment variables, or other factors
    return true
}

The isFeatureEnabled() function can return a simple boolean value, or it can involve more complex logic based on user attributes, environment variables, or external configuration management systems.

From an SRE perspective, feature flags offer several key benefits:

Risk Mitigation: By gradually rolling out new features to a subset of users, SREs can minimize the impact of potential failures and reduce the risk of outages. If a feature introduces performance issues or unexpected behavior, it can be quickly disabled without affecting the entire user base.
Rapid Rollbacks: In the event of a critical bug or performance degradation, feature flags act as kill switches, allowing SREs to quickly disable problematic functionalities without resorting to complete rollbacks. This helps maintain system stability and reduces the mean time to recovery (MTTR).
Controlled Experiments: Feature flags enable SREs to conduct controlled experiments, such as A/B testing or canary releases, to assess the performance and user impact of new features. This data-driven approach aligns with SRE practices of making informed decisions based on metrics and evidence.

Implementing feature flags requires careful consideration of factors such as flag management, data consistency, and performance overhead. SREs must establish clear naming conventions, define flag lifecycle policies, and ensure that flag evaluations do not introduce significant latency to the application.

Feature Management: Orchestrating Flags at Scale

While feature flags provide the tactical means to control individual functionalities, feature management offers a strategic framework for overseeing and orchestrating the entire lifecycle of feature flags across multiple services and environments. Feature management platforms provide a centralized interface for creating, configuring, and monitoring feature flags, as well as analyzing their impact on system behavior and user engagement.

From an SRE's standpoint, feature management is crucial for maintaining system stability, optimizing resource utilization, and ensuring a smooth user experience. By centralizing flag management and providing a holistic view of feature interactions, SREs can proactively identify potential conflicts, monitor feature-level metrics, and make informed decisions about feature rollouts and rollbacks.

Key aspects of feature management that are particularly relevant to SREs include:

Integration with Monitoring and Alerting: Feature management platforms can be integrated with existing SRE toolchains, such as monitoring systems and incident management platforms. This allows SREs to set up alerts for abnormal flag behavior, track feature-level metrics, and quickly identify and respond to issues.
Compliance with SLOs and Error Budgets: Feature flags and feature management can help SREs stay within their defined service level objectives (SLOs) and error budgets. By controlling the exposure of new features and quickly disabling problematic functionalities, SREs can minimize the impact on system reliability and maintain the desired level of service.
Automation and Tooling: Feature management platforms often provide APIs and SDKs that can be integrated with SRE automation and tooling. This allows SREs to programmatically manage feature flags, automate rollout and rollback processes, and incorporate feature flag checks into their existing workflows.

Progressive Delivery: The Convergence of Feature Flags and Feature Management

Progressive delivery is an umbrella term that encompasses various deployment strategies aimed at reducing the risk and increasing the velocity of software releases. Techniques such as canary releases, blue-green deployments, and dark launches rely heavily on the effective use of feature flags and feature management.

For SREs, progressive delivery is a key approach to ensuring the stability and reliability of production systems while enabling rapid innovation. By leveraging feature flags and feature management, SREs can implement progressive delivery practices that allow for the gradual and controlled rollout of new features, minimizing the blast radius of potential issues.

Challenges and Best Practices

While feature flags and feature management offer significant benefits, they also introduce certain challenges that SREs must navigate:

Flag Proliferation: As the number of feature flags grows, managing them can become complex and error-prone. SREs should establish clear guidelines for flag creation, documentation, and retirement to prevent flag sprawl and technical debt.
Performance Impact: Evaluating feature flags on every request can introduce performance overhead, especially in high-traffic scenarios. SREs should optimize flag evaluation logic, leverage caching mechanisms, and monitor the performance impact of feature flags.
Consistency and Synchronization: In distributed systems, ensuring the consistency of flag states across multiple services and instances can be challenging. SREs should implement robust synchronization mechanisms, such as distributed configuration stores or event-driven architectures, to maintain flag coherence.

To address these challenges and ensure the effective use of feature flags and feature management, SREs should adhere to the following best practices:

Establish Clear Naming Conventions: Use descriptive and meaningful names for feature flags, following a consistent naming scheme that reflects the purpose and scope of each flag.
Implement Flag Lifecycle Management: Define a clear lifecycle for feature flags, including creation, activation, deactivation, and retirement. Regularly review and clean up stale or unused flags to maintain a lean flag inventory.
Monitor and Alert on Flag Usage: Implement monitoring and alerting mechanisms to track the usage and performance of feature flags. Set up alerts for abnormal flag behaviors, such as sudden spikes in flag evaluations or inconsistent flag states across instances.
Collaborate with Development Teams: SREs should work closely with development teams to define flag-driven development practices, establish flag management policies, and foster a culture of experimentation and iterative delivery. This collaboration ensures that feature flags are used effectively and align with the overall goals of the organization.

The Future of Feature Flags and Feature Management

As software systems continue to grow in complexity and scale, the importance of feature flags and feature management will only increase. SREs can expect to see further advancements in these areas, such as:

AI-Driven Flag Optimization: Machine learning algorithms can analyze historical flag usage patterns and user behavior to recommend optimal flag configurations and rollout strategies.
Automated Flag Discovery and Synchronization: Advanced feature management platforms may employ techniques like static code analysis and runtime instrumentation to automatically discover and synchronize feature flags across multiple codebases and environments.
Integration with Chaos Engineering: Feature flags can be used as a tool for chaos engineering experiments, allowing SREs to inject controlled failures or simulated load into specific feature paths to assess the resilience and performance of the system.
Decentralized Flag Management: With the rise of microservices and distributed architectures, decentralized flag management approaches, such as using service meshes or distributed key-value stores, may become more prevalent to ensure flag consistency and reduce reliance on a single centralized platform.

Feature flags and feature management are essential tools in the SRE's arsenal for enabling progressive delivery, improving system resilience, and optimizing the user experience. By understanding the technical nuances of these methodologies and applying best practices, SREs can effectively leverage feature flags and feature management to navigate the complexities of modern software development.

As the landscape of software engineering continues to evolve, SREs must stay abreast of the latest advancements in feature flag and feature management technologies, embracing new approaches and integrating them into their progressive delivery workflows. By doing so, they can ensure that their systems remain agile, reliable, and responsive to the ever-changing needs of users and businesses alike.

Getting started with CloudBees DORA metrics

Drew Piland — Wed, 27 Mar 2024 17:10:55 +0000

DORA metrics help measure and improve the performance of software delivery teams. They help companies understand how well their engineering teams are performing in driving business value. Through these metrics, teams can identify bottlenecks in the software delivery process and help improve its effectiveness. DORA metrics are foundational for companies seeking to implement value stream management (VSM) initiatives.

This tutorial will explain the four DORA metrics, address the questions they answer, and examine how DORA metrics are instrumented within the CloudBees platform. This blog targets engineering managers seeking more visibility into how their software delivery efforts impact business performance.

UI overview

Before moving into each widget, let’s discuss some common UI elements:

Filtering: Use the filters to choose the component and the duration for which I want to see flow metrics down to the component level. When filtering, please note that weeks run from Monday to Sunday.
Drill downs: You can click any data point in the bold blue font for a deeper dive.
Hovering: Each report has a tooltip explaining its coverage. You can hover over each graph type to get a breakdown.
Viewing: All CloudBees platform pages can be viewed in either light or dark mode. We use dark mode for this post.

DORA metrics have been studied for several years and, thus, act as a benchmark to help organizations determine where they fit, broken down from elite to low performers. All teams are different in terms of what level they strive to achieve. When setting your software delivery goals, you must know your current status and incorporate measures to help you progress in your performance metrics.

DORA metrics in the CloudBees platform

DORA metrics within the CloudBees platform are available at the organization, sub-organization, or component level.

Let’s start by zooming in on the top row where the four DORA metrics are displayed.

Deployment frequency

Deployment frequency helps answer questions about how often software deployments are made to production. Overall, deployment frequency provides valuable insights into the team's agility, speed, and ability to release software to production, helping teams identify opportunities to optimize their release process and deliver new features and fixes more quickly and reliably.

In our example, we average 19.55 deployments per day. As a software vendor developing a new product, it makes sense to have such a high frequency when adding core functionality.

While increasing deployment frequency indicates an agile team, ensuring you are deploying the right features is vital. Thus, ensuring deployment frequency isn’t measured in isolation is necessary for optimal outcomes.

When benchmarking performance:

Elite Performers: Multiple times a day
High Performers: Once a week to once a month
Medium Performers: Once a month to once every six months
Low Performers: Less than once every six months

Deployment lead time for changes

Lead time for changes measures the time it takes for a code change to be implemented and deployed to production. It provides valuable insights into the team's efficiency and speed in implementing and deploying changes, helping teams identify areas for improvement and optimize their development and release process to reduce lead time and improve customer satisfaction.

Our example shows a deployment lead time for changes of four minutes and two seconds. This number will likely increase as the product matures and the team grows. Engineering managers should be aware of several factors that could lead to slower lead time for changes, such as:

Poor communication: Projects often involve large, dispersed teams, which can lead to misunderstandings of requirements. As a manager, you can reduce this likelihood by creating appropriate-sized and centralized teams.
Tech debt: impacts lead time as old issues must be addressed.
Lack of automation: manual building, testing, and deploying processes can significantly slow lead time. Ensure automation is incorporated as necessary to help.
Lack of resources: if a team needs more resources (people or infrastructure), this can slow down the deployment process.
Regulatory compliance: Highly regulated industries often require additional rigorous checks before deployment, impacting the lead time.

When benchmarking performance:

Elite Performers: Less than one hour
High Performers: One day to one week
Medium Performers: One month to six months
Low Performers: More than six months

Change failure rate (CFR)

Change failure rate provides valuable insights into the reliability of the team's release process and the quality of their releases. Low failure rates are desirable. For example, a 10% change failure rate indicates that 10% of all changes made to the system failed.

These insights help engineering managers identify areas for improvement and optimize their release process to reduce the risk of failed changes and improve customer satisfaction. For example, a high CFR may indicate that too many changes are being introduced simultaneously. High CFR also raises the question of investment in tooling and infrastructure. If the change failure rate continues to be high, there’s also a cultural impact on morale, leading to lower developer productivity.

When benchmarking performance:

Elite Performers: 0-15%
High, Medium, and Low Performers: 16-30%

Mean time to recovery (MTTR)

MTTR provides valuable insights into the effectiveness of the team's incident response process, helping identify areas for improvement and optimize their incident management process to reduce downtime and improve customer satisfaction. Teams should strive to make this number as low as possible. MTTR helps address questions such as:

How quickly can development teams respond to and recover from incidents?
How effective is the team’s incident management process?
How much downtime does the team experience?

When benchmarking performance:

Elite Performers: Less than one hour
High Performer: Less than one day
Medium Performers: One day to one week
Low Performers: Over six months

Additional insights

The DORA reports section of the CloudBees platform goes beyond the four metrics. We also offer two trend reports to provide teams with additional insights.

Deployment frequency and lead time trend

This widget tracks the number of deployments and lead time for the selected date. These two metrics work together for the following purposes:

Assessing Efficiency: A high deployment frequency coupled with a short lead time for changes indicates an efficient and effective software delivery process—teams can frequently deliver small, manageable changes with minimal delay.
Identifying Bottlenecks: If deployment frequency is high but lead time for changes is also high, it may indicate that while the team is deploying often, it's taking a long time for those changes to go from idea to deployment. This could point to development, testing, or deployment bottlenecks.
Balancing Speed and Stability: If deployment frequency is low but the lead time for changes is also low, it suggests that the team is focusing on delivering large batches of changes quickly. This could lead to a risk of instability or issues in production. Balancing the two metrics can help achieve speed and stability in the delivery process.

By monitoring both deployment frequency and lead time for changes, software delivery teams can better understand their delivery process, identify areas for improvement, and make more informed decisions about optimizing their workflow.

Failure rate and mean time to recovery trend

This widget tracks the number of failed deployments and the mean time to recovery (MTTR) for the select dates. These two metrics work together for the following purposes:

Identifying Problem Areas: A high failure rate and a high MTTR could indicate serious problems with the system's reliability and resilience. This might suggest the need for a thorough review and overhaul of the system.
Improving System Design: Understanding the relationship between failure rate and MTTR can help teams design better systems. For example, if the failure rate is high but MTTR is low, it might be due to frequent minor issues that are quickly resolved. This could lead to a focus on improving overall software quality to reduce the number of minor issues.
Balancing Resources: If the failure rate is low but MTTR is high, it might indicate that while the system is generally stable, significant issues take a long time to resolve. This could suggest the need for more resources to be put into faster problem detection and diagnosis or building more robust recovery mechanisms.

By monitoring and understanding both the failure rate and MTTR, software delivery teams can gain valuable insights into their system's performance, identify areas for improvement, and make informed decisions about where to invest resources for the most significant impact.

Configuring DORA metrics in the CloudBees platform

As of March 2024, DORA metrics rely on users tagging steps as Deploy within the Kind operator. Once applied, all data will funnel into the tabs. To learn more about this, visit our documentation.

Next steps

The CloudBees platform offers organizations a quick way to access DORA metrics, with granularity down to the organization, sub-organization, and component level. Equipped with this information, engineering managers can track the progress of delivering business impact with the ability to communicate this upstream efficiently.

With the information provided throughout this blog, you should better understand DORA metrics, how to set them up, and how to interpret the results. Now, it’s time to get started. Try the CloudBees platform for free to put these steps into practice. For complete documentation on DORA metrics, click here.

To learn more about additional CloudBees analytics reports, visit the below documentation.

CloudBees Security Insights Overview

Drew Piland — Mon, 18 Mar 2024 13:30:13 +0000

The CloudBees security insights report provides detailed insights into the results of security scans to users. It helps software development teams, security officers, and CISOs gain insights into security vulnerabilities and bugs so that users can quickly resolve such issues and improve the overall quality of their software. The report provides a single bird's eye view of how vulnerable an organization, sub-organization, or component is.

This blog aims to provide an overview of each widget, explain its value, and demonstrate how to act on the vulnerability insights presented. Users would visit this report to answer several questions:

How vulnerable are our workflows to breach? What is the severity level?
When vulnerabilities appear, do we know where they occur for remediation purposes? Are we improving our response time based on this information?
Which scanner types are we using? What percentage of workflows are these in?
What percentage of workflows are breaching SLA?

How does all this work?

Each widget uses a scalable and flexible Cassandra database to ingest data from workflows, scans, and integrations like JIRA. The data is indexed by an open search cluster, where an analytics service provides some pre-computation services so that the data is already pre-computed for all the widgets. When a user opens one of the reports, it connects to the report service via a secure API gateway for quick access.

UI overview

Before moving into each widget, let’s discuss some common UI elements:

Filtering: Use the filters to choose the component, duration, org, and sub-org level. Please note that weeks run from Monday to Sunday. Our overview will focus on data for December 2023, cloudbees-staging org level, and all its components.
Drill downs: Click any data point in the bold blue font for a deeper dive. Most widgets in this report allow you to view the vulnerability ID, components affected, the scanner user, and insight into the impacted line of code with a direct link to the GitHub repository.
Hovering: Each report has a tooltip explaining its coverage. You can hover over the data for each graph type to get a breakdown.
Viewing: All CloudBees platform pages can be viewed in either light or dark mode. We use dark mode for this blog.

Components, workflows, and successful workflow runs

Our first set of widgets aggregates information and tells you how many components and other workflow runs exist, along with their scanner status. You can see there are 489 components with 468 repos, broken out by how many components have a scanner or are without a scanner. So, out of 489 components, 51 have some kind of scanner, and 438 have no attached scanners.

Additionally, I can click on the 51 components, which tells you which scanners exist. For example, in the analytics component, snykcast and sonarqube scanners exist.

The Workflows widget provides a breakdown of workflows, highlighting those equipped with scanners versus those without security scanners. Here, it tells you that 489 components have 3,713 workflow files, composed of 2,221 branches, of which 141 workflows have some kind of scanners, and 3,572 workflows have no scanners.

You can drill down into which workflows have no scanners attached. Similarly, if you click on 246 workflows, you can see which scanner is attached to run as part of this workflow.

These 3,713 workflows ran 12,570 times, of which 504 times included a scan step and 12,066 times there was no scan step.

By better understanding your security scanner coverage across workflows and components, engineering managers, security officers, and CISOs unlock visibility into their threat level and can take action. The summary record shows how often workflows are run with or without a scanner. Typically, running workflows without scanners in the early stages of development is okay. Still, as an enterprise customer, you want to avoid having production deployment of code that was never scanned.

Vulnerabilities overview

The vulnerabilities overview widget tells you how many vulnerabilities are found, reopened, resolved, or open. Let’s define these categories:

Found: new vulnerabilities encountered for the first time (i.e., not specific to the current duration) for a component. Reopened: vulnerabilities previously encountered and resolved are now showing up again.
Resolved: vulnerabilities discovered earlier but not appearing in the latest scan of the specified period are considered resolved.
Open: vulnerabilities appearing in the latest scan of the specified period.

For December, we found 415 vulnerabilities, reopened one, resolved nine, and 406 remain open. Let’s drill down into found vulnerabilities.

When I click on 415, I see a Vulnerabilities Overview screen, which includes ID, discovery date, name, stats, severity, and impacted components. Next, I decided to drill down into the vulnerability ID of CWE-259 since it has a very high severity. I now want to dig deeper into the occurrence from the snykcast scanner and see the exact repo location, if available. In this instance, it exists on line 50. This highlights how granular these reports are and how they allow security teams to troubleshoot for root cause issues.

Open and reopened vulnerabilities
The reopened vulnerabilities widget provides the mean age of open vulnerability occurrences by severity, showing 37 vulnerabilities are very high severity, 105 are high severity, 164 are medium severity, and 100 are low severity. I can further click on these numbers and get a drill down of these 37 very high vulnerabilities, which is where I should prioritize.

For example, I can drill down into CW-295 and notice the vulnerability name is some kind of improper certificate validation that needs fixing. I can click on this number of occurrences, click on number four, and see the repo, file, and line number where this is happening.

This widget also tells you the vulnerability criticality level (very high, high, medium, and low) and how long they've been open (mean, median, max) using a box plot on a candlestick chart—ideally, the higher the severity, the quicker the resolution time.

Scanner types

These widgets focus on better understanding the utilization of your security scanners.

Scan types in workflows
The scan types in workflows widget track the distribution and frequency of four scan types:

Static application security testing (SAST): SAST takes an “inside-out” approach to finding security vulnerabilities by analyzing the app’s source code in a nonrunning state.
Dynamic application security testing (DAST): Like SAST, DAST also focuses on finding security vulnerabilities by analyzing the source code. However, DAST differs in that it does this while the application is running. DAST solutions analyze the application from the "outside-in" by simulating cyber attack behaviors and techniques.
Software composition analysis (SCA): This method achieves open-source software compliance and is used to identify open source components with known vulnerabilities.
Container scanners: These tools help identify issues with your container images, such as outdated libraries, dependencies, or potential vulnerabilities. They can be used as part of a CI/CD pipeline to catch potential security issues before they make it into production.

The scan types across workflows help ensure consistent security evaluations. It also tells you how many workflow runs are part of which scanner type. For example, 156 workflows with a SAST scanner type execute 470 workflow runs.

Vulnerabilities by security scan type
Whereas the scan types in the workflows widget display the number of workflows and workflow runs by scanner type, the security scan type widget tells you how many of these vulnerabilities were found. This widget further breaks the number of vulnerabilities found by very high or high for different security scan types, so you can see how many of them are high, very high, or low per category of a security scan type.

For example, we found 44 vulnerabilities of SAST, 17 of DAST, 253 from container scans, and 112 vulnerabilities from SCA. You can click further into each of these to determine the affected component and drill down to the GitHub repo and line level.

SLA status overview by occurrences

For the SLA status overview by occurrences widget, we have defined some SLAs in the current version that should fix vulnerabilities within three days.

On track: less than two days
At risk: two days
Breach: after three days, we mark it as breached.
Please note these SLA statuses are hard-coded for all users but can be modified on an account or user basis. Please reach out to your CloudBees representative to assist here.

For all open vulnerabilities, seven are on track, zero are at risk, and 3,098 open vulnerabilities have breached the three-day marker to break our SLA. This view provides a benchmark for tracking vulnerability resolution time moving forward.

Mean Time to Resolve (MTTR) for vulnerabilities occurrences

The mean time to resolve (MTTR) for vulnerabilities occurrence tracks how long it takes users to fix vulnerabilities based on severity type. If MTTR is improving monthly, that shows the team is solving vulnerabilities more efficiently.

Further, we break these numbers down weekly to see how fast the engineering teams have resolved our vulnerabilities.

CWE top 25 vulnerabilities

The CWE Top 25 is a list compiled by MITRE that lists common security vulnerabilities with the most severe impact. This widget lets you instantly identify impacted components, how many occurrences, and the SLA status to help troubleshoot to understand better how exploitable the system is.

Within the cloudbees-staging organization, we detected five of these vulnerabilities. Further, I can click on any of these components, and this will give me a drill down of what those components are.

Next Steps

The security insights report provides an aggregated view of your vulnerability status across workflows. The report aims to provide software development teams, security officers, and CISOs with insights into security vulnerabilities to help quickly resolve issues and improve software quality. Using this report, you can quickly answer the following questions:

Which scanners are currently in our workflows?
How many vulnerabilities are we seeing weekly?
What is the severity breakdown of our vulnerabilities?
How quickly are we addressing vulnerabilities?
What scan types are we using, and how does this relate to severity?
How often are we breaching SLAs?

youtube.com

Now that you understand this report better, it’s time to start. Try the CloudBees platform for free. For complete documentation on security insights, click here.

To learn more about additional CloudBees analytics reports, visit the documentation below.