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

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.

Build With CloudBees Platform and Win an Exclusive T-shirt

CloudBees — Thu, 22 Feb 2024 17:05:28 +0000

Win back some time to do actual coding with the new CloudBees DevSecOps platform. Take advantage of our secure, self-service, composable, reusable workflows to speed software to production. The CloudBees platform presents a comprehensive DevOps solution, empowering teams to craft and execute efficient CI/CD workflows.

For those new to the platform, through the end of March, we will select 10 lucky users each week to receive a cool t-shirt. All you have to do is to submit a workflow created using the CloudBees platform. See below to learn more!

Create a CI/CD Workflow and Get a Free T-shirt

CloudBees is offering a chance to win a free t-shirt to users who sign up for the platform (it’s FREE), create a workflow, and share your results on social media.

Here are the steps to submit a CI/CD workflow and get a cool t-shirt:

Sign up for a free CloudBees platform account
Create a connection to your source repository
Create a new component
Define a workflow using the graphical composer or the built-in YAML editor
Trigger your workflow to execute it
Take a screenshot of your workflow and share it on LinkedIn, X, or Facebook, with both #CloudBeesPlatform #CoolDevT hashtags. Also, be sure to tag @CloudBees in your post. Each week, we’ll choose 10 lucky users to get a free t-shirt! (To be shipped at the end of March.)

Watch this step-by-step video to learn how to create a workflow:

What is a CI/CD Workflow?

CI/CD stands for continuous integration and continuous delivery. CI/CD are a set of practices and automated processes that enable teams to deliver software more frequently and reduce tedious, manual, time-consuming processes. A CI/CD workflow typically involves several stages, such as code management, build automation, security and code quality scanning, testing, deployment, and release. The main aim of a CI/CD workflow is to reduce the time and effort required to deliver software, securely, while maintaining quality and stability

The Benefits of Using CloudBees

CloudBees is a cloud native, end-to-end DevOps solution that, among other things, enables teams to create and run CI/CD workflows. CloudBees offers several benefits for teams, such as:

Scalability: CloudBees platform can scale to meet the needs of any size organization, from startups to large enterprises.
Flexibility: CloudBees platform supports multiple cloud providers and integrates with many tools and technologies.
Security: CloudBees provides built-in security, as well as RBAC for managing access and permissions.
Visibility: CloudBees offers real-time dashboards and reporting that enable teams to track the progress of their CI/CD workflows and identify bottlenecks or issues.

The CloudBees platform is the DevOps solution that allows teams to create and run efficient CI/CD workflows, by accelerating software delivery with scalability, flexibility, security, and visibility. Don't miss the chance to win a free t-shirt by signing up and sharing your workflow!

The Future of DevSecOps with the CloudBees Platform—An In-Depth Look

CloudBees — Tue, 20 Feb 2024 22:05:06 +0000

The new CloudBees platform was launched in November of last year. In this blog, we will set the stage for why and how we developed the CloudBees platform by describing the two types of applications that dominate software delivery today, the challenges DevSecOps teams face and, finally, the way the CloudBees platform was architected to address those challenges. Let's go!

Today's digital ecosystem is buzzing with a myriad of applications, each with distinct characteristics and requirements. Two prominent types dominate this ecosystem: cloud native and traditional applications. Addressing the unique DevSecOps requirements of both these applications is crucial, and this is where the new CloudBees platform shines.

The Dichotomy of Modern Software Applications

Cloud Native Applications: These applications, born in the mid-2010s, have been propelled by the rising influence of public cloud infrastructures, Docker container technologies, and Kubernetes management platforms.

Traditional Applications: Encompassing a range from applications deployed in application servers to non-containerized applications deployed to traditional server infrastructure these are the software world's current stalwarts. Some are transitioning into cloud native applications, while many retain their original forms due to unique non-cloud native use cases.

Both categories have longevity, though their proportions might evolve.

DevSecOps Challenges

The CloudBees platform stands at the intersection of cloud native advancements and traditional application legacies. It promises a cohesive, unified experience from code commit to deployment. Envision a realm where developer experience and productivity harmoniously coexist. This isn't just a tool—it's a culture.

Enhanced developer experience remains a constant across cloud native and traditional applications.

As Jim Mercer, IDC Research Vice President DevOps and DevSecOps, articulated:

"Developer experience, security, and efficiency often conflict with DevSecOps, and too much complexity shifts onto developers. Solutions such as the new CloudBees platform, which combines cloud native tools like Tekton-based pipeline automation and a graphical workflow composer, can pull these workstreams closer, creating a paved path for developers to innovate more securely."

This accentuates the responsibility on platform engineering teams to provide an uninterrupted self-service experience for developers.

CloudBees: Bridging the Gap

CloudBees offers a tailor-made solution for the distinct DevSecOps demands of both application types.

The CloudBees platform helps developers efficiently handle Kubernetes deployments, powered by Tekton with an extended actions syntax.

Spike Washburn, engineering leader at CloudBees, explained:

"We talked about should we adopt something that already exists, such as Tekton, a Kubernetes-centric YAML language for describing automations running in a Kubernetes cluster? Or should we adopt something closer to a GitHub Actions DSL for ease of use? Our choice was to create a DSL that is closely aligned to GitHub Actions, yet provides the power of Tekton while abstracting away the complexity of Kubernetes. In doing so, we provide ease of use for all developers, even those who aren't Kubernetes experts."

CloudBees ensures existing tool investments remain intact while boosting deployment capabilities for conventional environments.

The DSL From CloudBees

The new DSL simplifies the creation, assessment, and repurposing of workflows for all staff, regardless of their coding proficiency. It's harmonized with actions from other vendors, but it's not a keyword match. A powerful action library enhances its GitHub Actions compatibility and facilitates powerful reuse mechanisms for both existing and custom-made actions. The platform's usability is not limited to the actions library. Users can easily integrate or modify workflow templates via a visual editor in the CloudBees platform.

While CloudBees maintains a strong bond with Jenkins and offers connectivity, its platform is fundamentally constructed using Tekton to dispatch jobs to Kubernetes, meaning Jenkins is not required for job execution or orchestration. However, CloudBees platform can still orchestrate Jenkins, CloudBees CI, and other DevOps tools in hybrid environments.

CloudBees platform encompasses workflow and actions DSLs, simplifying the creation of fresh pipelines and jobs. These DSLs share multiple parallels with other tools, including the structure and several keywords. Replication of actions you are currently using becomes straightforward using the inherent actions library or tailored scripts.

A notable distinction between CloudBees platform and other tools resides in action execution. CloudBees utilizes containers, offering enhanced workflow state support due to its dependency on containers and Kubernetes.

The CloudBees Advantage

Cloud native workflows: Leveraging the intrinsic Tekton-based system of the CloudBees platform.
External CI/CD workflows: Orchestrating eminent tools like Jenkins, CloudBees CI, GitHub Actions, and more.
Hybrid workflows: Blending the best of both of the above.
Jenkins-centric workflows: Expected by 2024, there will be Jenkins-integrated workflows within the CloudBees platform

Organizations can cherry-pick from these, aligning with factors like application types and their modernization vision.

CloudBees platform is a pioneer in addressing the evolving DevSecOps challenges confronting organizations. Catering to both cloud native and traditional applications, it ensures organizations glide through the digital domain with agility, security, and efficacy.

Today, we celebrate the CloudBees platform, but we’re even more eager for tomorrow. Our journey is about evolving, about looking ahead, and ensuring we're not just meeting but anticipating your needs.

The CloudBees platform isn't a one-size-fits-all solution, because no such solution truly exists in the diverse world of software delivery. Instead, we offer a spectrum of use cases, adaptable and moldable, to ensure that every organization, irrespective of its unique landscape and vision, finds its perfect fit. The future of DevSecOps is not just about innovation; it's about tailored innovation.

Welcome to the future, powered by CloudBees. Take a leap, see the difference, and let’s craft the future of DevSecOps together.

How to Disable Code: The Developer’s Production Kill Switch

CloudBees — Mon, 15 Jun 2020 15:21:16 +0000

The following is a guest post written by Carlos Schults.

Being able to disable code in production is a power that many developers aren’t aware of. And that’s a shame. The ability to switch off some portions—or even complete features—of the codebase can dramatically improve the software development process by allowing best practices that can shorten feedback cycles and increase the overall quality.

So, that’s what this post will cover: the mechanisms you can use to perform this switching off, why they’re useful and how to get started. Let’s dig in.

Why Would You Want to Disable Code?

Before we take a deep dive into feature flags, explaining what they are and how they’re implemented, you might be asking: Why would people want to switch off some parts of their codebase? What’s the benefit of doing that?

To answer these questions, we need to go back in time to take a look at how software was developed a couple of decades ago. Time for a history lesson!

The Dark Ages: Integration Hell

Historically, integration has been one of the toughest challenges for teams trying to develop software together.

Picture several teams inside an organization, working separately for several months, each one developing its own feature. While the teams were working in complete isolation, their versions of the application were evolving in different directions. Now they need to converge again into a single, non conflicting version. This is a Herculean task.

That’s what “integration hell” means: the struggle to merge versions of the same application that have been allowed to diverge for too long.

Enter the Solution: Continuous Integration

“If it hurts, do it more often.” What this saying means is that there are problems we postpone solving because doing so is hard. What you often find with these kinds of problems is that solving them more frequently, before they accumulate, is way less painful—or even trivial.

So, how can you make integrations less painful? Integrate more often.

That’s continuous integration (CI) in a nutshell: Have your developers integrate their work with a public shared repository, at the very least once a day. Have a server trigger a build and run the automated test suite every time someone integrates their work. That way, if there are problems, they’re exposed sooner rather than later.

How to Handle Partially Completed Features

One challenge that many teams struggle with in CI is how to deal with features that aren’t complete. If developers are merging their code to the mainline, that means that any developments that take more than one day to complete will have to be split into several parts.

How can you avoid the customer accessing unfinished functionality? There are some trivial scenarios with similarly trivial solutions, but harder scenarios call for a different approach: the ability to switch off a part of the code completely.

Feature Flags to the Rescue

Defining Feature Flags

There are many names for the mechanisms that allow developers to switch a portion of their code off and on. Some call them “feature toggles” or “kill switches.” But “feature flags” is the most popular name, so that’s what we’ll use for the remainder of this post. So, what are feature flags?

Put simply, feature flags are techniques that allow teams to change the behavior of an application without modifying the code. In general, flags are used to prevent users from accessing and using the changes introduced by some piece of code, because they’re not adequate for production yet for a number of reasons.

Disable Code: What Are the Use Cases?

We’ll now cover some of the most common use cases for disabling code in production.

Switching Off Unfinished Features

As you’ve seen, one of the main use cases for feature flags is preventing users from accessing features that aren’t ready for use yet.

That way, programmers developing features that are more complex and take a longer time to complete aren’t prevented from integrating their work often and benefiting from it.

Enabling A/B Testing

The adoption of feature flags enables the use of several valuable practices in the software development process, one of which is A/B testing.

A/B testing is a user experience research technique that consists of comparing two versions of a website or application to decide which one to keep. It entails randomly splitting users into two groups, A and B, and then delivering a different version of the application to each group. One group might receive the current production version, which we call the “control,” whereas the second group would receive the candidate for the new version, called the “treatment.”

The testers then monitor the behavior of both groups and determine which of the versions achieved better results.

Feature flags are a practical way to enable A/B testing because they allow you to quickly and conveniently change between the control and treatment versions of your application.

Enabling Canary Releases

If you deliver the new version of your app to your entire userbase at once, 100 percent of your users will be impacted if the release is bad in some way. What if you could gradually roll out the new version instead? You’d first deploy to a small subset of users, monitoring that group to detect issues. If something went wrong, you could roll it back. If everything looked fine, you could then gradually release the version for larger groups. That’s a canary release in a nutshell. It’s another powerful technique that feature flags might help with.

Customizing Features According to Users’ Preferences

It’s not uncommon to have to customize your application according to the needs of specific users, and there are several ways in which software teams can accomplish that—some more efficient, and others less so (companies that create separate branches or entire repositories for each client come to mind).

This is another area where feature flags could help, allowing teams to dynamically switch between different versions of the same functionality.

Disable Code in Production 101

How do you go about disabling code? That’s what we’re going to see now, in three increasingly sophisticated phases.

First Stage: The Most Basic Approach

We start with an approach that’s so primitive, it maybe shouldn’t be considered a feature flag at all. Consider the pseudocode below:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

    var result = useNewCalculation
        ? calculateAdditionalWorkHoursImproved(employee, start, end)
        : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

    return result;
}

In the code above, we’re just commenting out the old version of some method and replacing it with a new version. When we want the older version to be used, we just do the opposite. (Well, I said it was primitive.) This approach lacks one of the most fundamental properties of a feature flag—the ability to change how the application behaves without changing its code.

However, it plants the seed for more sophisticated approaches.

Second Stage: Taking the Decision Out of the Code

The previous approach didn’t allow developers to select the desired version of the feature without changing the code. Fortunately, that’s not so hard to do. First, we introduce a logical variable to determine which version we’re going to use:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

    var result = useNewCalculation
        ? calculateAdditionalWorkHoursImproved(employee, start, end)
        : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

    return result;
}

Then, we use some mechanism to be able to assign the value to the variable from an external source. We could use a configuration file:

var useNewCalculation = config[newCalculation];

Passing arguments to the application might be another option. What matters is that we now have the ability to modify how the app behaves from the outside, which is a great step toward “true” feature flagging.

Keep in mind that the code examples you see are all pseudocode. Using your favorite programming language, there’s nothing stopping you from starting with this approach and taking it up a notch. You could, for instance, use classes to represent the features and design patterns (e.g., factories) to avoid if statements.

Stage 3: Full-Fledged Feature Flag Management

The previous approach might be enough when your application has only a small number of flags. But as that number grows, things start to become messy.

First, you have the issue of technical debt. Manually implemented feature flags can create terribly confusing conditional flows in your codebase. That only grows worse with new flags being introduced each day. Additionally, they might make the code harder to understand and navigate, especially for more junior developers, which is an invitation for bugs.

Another problem is that as the number of flags grows, it becomes more and more common to forget to delete old, obsolete ones.

The main problem of a homegrown approach is that it doesn’t give you an easy way to see and manage all of your flags at once. That’s why our third and final stage is a single piece of advice: Instead of rolling out your own feature flags approach, adopt a third-party feature flag management system.

Feature Flags Are a CI/CD Enabler

We’ve covered the mechanisms developers can use to disable portions of their codebase in production without having to touch the code. This capability is powerful and enables techniques such as A/B testing and canary releases, which are all hallmarks of a modern, agile-based software development process.

The names for the techniques might vary—feature flags, feature toggles, feature flipper, and so on. The way in which the techniques are implemented can also vary—from a humble if statement to sophisticated cloud-based solutions.

But no matter what you call them, you can’t overstate the benefit these mechanisms offer. They’re an enabler of Continuous Integration, which is essential for any modern software organization that wants to stay afloat.