devopsy.kinsta.cloud

Category: Continuous Delivery

Why DevOps is Key to Software Supply Chain Security

DevOps is designed to increase business value and responsiveness through rapid, high-quality service delivery, made possible through fast-paced, iterative IT service delivery. The term DevSecOps emerged as a way to remind us that security was always intended to be part of the software delivery process. However, with the barrage of attacks on the software supply chain showing no signs of abating, the question now is whether even the tightest DevOps pipelines can maintain the pace-protection balance.

It’s important to note that the term “software supply chain” has been used primarily to refer to the tools and processes used to build and deploy software applications. Now, however, with the rise of infrastructure-as-code (IaC), the term also refers to tools and processes used to build and deploy IT infrastructure.

Meet Mandates, Reduce Risk

Software supply chain attacks such as SUNBURST, HTTP/2 Rapid Reset or the breaches associated with the MOVEit vulnerability have fed news cycles for the last few years, and that likely won’t change anytime soon. Attacks on the software supply chain increased 742% since 2020. What we are seeing as a result are new concerns about supply chain security and DevOps requirements. This has led to confusion and often a mish-mash of tooling that may exacerbate rather than mitigate supply chain security issues.

Arguably the most impactful salvo over the software supply chain security line was president Biden’s 2021 Executive Order 14028, which established new mandates, including the delivery of SBOMs, as minimum requirements for software used by the U.S. federal government. More recently, the FDA has mandated that “all medical devices running software must create and maintain” SBOMs. I expect to see government and industry requirements increase over time.

These are just a couple of relatively recent examples. There are many more—and no doubt many more to come.

So, if you’re moving at the speed of DevOps, how do you address these current and future mandates for software supply chain security, as well as the continually emerging vulnerabilities and attacks? I would venture to say that only by moving at the speed of DevOps—and within the parameters of the DevOps model—can organizations not only meet mandates but also effectively reduce risk for the business.

Indeed, it’s not a matter of whether DevOps is viable within the current security climate but what requirements need to be added to support and enhance current DevOps work.

New Guidelines, New Processes, New Tools and New Data

In response to these new threats and regulations, the software community has been working on developing and updating guidelines to help organizations improve the security of their supply chains—for example, SLSA, NCSC UK supply chain security guidance and NIST cybersecurity supply chain risk management. However, these new guidelines can be complicated and require new processes and new tools.

Before adding any new tooling or changing any processes, it’s critical to examine existing tools to determine whether and to what extent they satisfy supply chain security mandates. Organizations must also evaluate how well existing processes work to protect the business, then strategically add/subtract from there as needed.

No matter what solutions are leveraged, more and different tools generate reams of more and different data. What’s important — and to whom? How do I manage the data? When can I trust it? Where do I store it? What problems does the new data help me solve? Organizations will need a way to effectively sift this information and deliver the right data to the right teams at the right time. To preserve the ability to quickly and continuously innovate, it will be important to focus on shifting security left as well as integrating automation whenever and wherever possible.

As new security metadata becomes available, such as from SBOMs, new solutions for managing that metadata will be key. An open source initiative sponsored by Google, GUAC is designed to integrate software security information, including SBOMs, attestations and vulnerability data. Users can query the resulting GUAC graph to help answer key security concerns, including proactive, preventive and reactive concerns.

Continue to Shift Security Left

Another way that organizations can maintain their DevOps momentum while protecting the software supply chain is to continue to invest in shifting security left in the software supply chain. The software community has been talking about this for some time, but many organizations struggle to implement impactful changes. Security teams must work to understand how software is built and collaborate with development and DevOps teams to ensure that improvements are made to both application and infrastructure-as-code supply chains.

We need to go beyond shift-left vulnerability analysis to ensure that we are evaluating the quality of configuration-as-code (for both applications and infrastructure), that we are taking advantage of new recommendations, and that we are leveraging new attestation solutions designed to work with pipelines such as sigstore and Tekton Chains. After all, the sooner an issue is discovered, the more quickly it can be addressed and the less disruptive and costly it is to fix it.

No One-Size-Fits-All Solution

While all of these solutions mentioned here are helpful, there is no single product or framework that will enable organizations to maintain the security-innovation balance. Success, rather, will require a focus on agility, flexibility and effective communication and collaboration—the very hallmarks of the DevOps model.

Rather than being obviated by the demands of software supply chain security, DevOps provides the opportunity to integrate the kinds of protections that can prevent or mitigate supply chain vulnerabilities and breaches. DevOps also enables organizations to quickly and effectively respond to new threats and new requirements.

With that said, there’s no doubt that organizations will need to think differently about how they manage software security, including the strategic evaluation and integration of tools that will meet current and future regulatory mandates and, more importantly, protect the business over time. Organizations may also need to think about weighing security over speed, at least until all of the pieces of the software supply chain protection puzzle are in place—but also when future circumstances warrant a fresh look at how to best balance the DevOps pace-protection balance.

February 21, 2024
The Future of Continuous Testing in CI/CD

If you ever wonder why continuous testing is so important, think about the following: In the past, software testing was typically done after the code was written and sent to the QA department for independent testing. When bugs were discovered, the code was returned to the developers for correction. While this testing method worked, it was time-consuming. Nowadays, companies want to produce high-quality products quickly, so they need a faster and more efficient testing process. This is when continuous testing comes in.

In this article, we will explore continuous testing from its current state and its future in CI/CD to the emerging technologies and trends that will shape its development. We will also cover the importance of continuous testing for businesses and some of its challenges.

What is Continuous Testing?

Continuous testing is a software testing approach in which tests are automated and run throughout the software development life cycle. It is a part of the continuous delivery (CD) process, in which software changes are delivered to customers continuously and iteratively.

Continuous testing aims to identify defects and issues as early as possible, reducing the cost and time of fixing them later. Continuous testing provides immediate feedback to the development team, helping them to detect and address potential problems quickly and efficiently.

According to the Reports and Data source survey, 21% of QA professionals have incorporated continuous testing, source code management and continuous integration into their DevOps process to speed up code release.

Advantages of Continuous Testing

Here are several advantages of implementing continuous testing as a part of the software development process:
● Continuous testing enables teams to identify bugs earlier in the software development process;
● Continuous testing provides immediate feedback to developers on the quality of their code, enabling them to address any issues immediately;
● You can minimize business risks by assessing and identifying potential issues before they become real problems;
● Automating your test cases can reduce the time spent on testing;
● Accelerating the process of software delivery to production helps release the product faster;
● You can run performance tests in similitude, which can increase the speed of test execution.

Disadvantages of Continuous Testing

While continuous testing has become an integral part of the software development process, it’s not without its challenges. As software development teams work to incorporate testing into their CI/CD pipelines, they may encounter obstacles that can hinder their progress.
● Continuous testing requires a different skillset than traditional testing, including expertise in DevOps, automation and CI/CD pipelines;
● Different tools and technologies are available for continuous testing, and choosing the right ones can be tough. Integrating these tools with other parts of the development process can also be challenging;
● To fully realize the benefits of continuous testing, you need to update your testing strategy by moving away from relying solely on traditional testing methods and adopting a well-defined approach to test data management;
● Failing to integrate code regularly can result in issues such as duplicated coding efforts and non-compatible code, leading to defects.

Emerging Technologies in Continuous Testing

With the increasing demand for faster and more reliable software releases, emerging technologies such as AI/ML, automation and DevOps appeared in continuous testing. These technologies help teams to automate and streamline their testing processes, identify defects more quickly and improve overall software quality. Let’s examine some of them:

Artificial intelligence/machine learning (AI/ML). AI and ML refer to the field of computer science that deals with developing intelligent machines that can simulate human intelligence and learn from data.

One of the main benefits of AI and ML in continuous testing is the ability to automate test case generation, which reduces the need for manual testing and frees up time for other tasks. This enables testers to test applications more comprehensively and frequently, ensuring defects or issues are identified and addressed quickly. AI and ML increase testing accuracy by identifying patterns and anomalies in the testing data.

AI and ML techniques can efficiently and rapidly analyze extensive amounts of data, allowing them to recognize patterns and irregularities in testing data that human testers might overlook.

Automation: Automation in continuous testing refers to using automated tools and processes to execute software tests repeatedly and consistently. It involves automating various stages of the software testing life cycle, such as test planning, test case design, test execution and test reporting.

Automation can efficiently perform regression testing, ensuring that changes do not introduce new defects or issues in the software. Tests can be executed 24/7 without human intervention, reducing the time and cost required for testing.

DevOps: DevOps in continuous testing is the application of DevOps principles to continuous testing, focusing on integrating testing into the software development life cycle and enabling faster and more reliable delivery of software.

In the context of continuous testing, DevOps emphasizes testing integration into the development process, enabling developers to detect and fix defects early in the cycle. DevOps also promotes automation, collaboration and communication between development and operations teams, allowing faster and more efficient testing and deployment.

Blockchain: Blockchain technology has been gaining increasing attention in the software development and testing industry due to its ability to provide secure and tamper-proof data storage.

In continuous testing, blockchain stores testing results and data in a decentralized and transparent way, making it virtually impossible for anyone to modify or manipulate the data. This enhances the credibility of the testing process and outcomes and provides an added layer of security to ensure the integrity of the data.

Blockchain technology enables efficient and seamless data sharing between stakeholders involved in the testing process, enabling faster and more accurate decision-making.

Internet-of-Things (IoT): In continuous testing, IoT simulates many IoT devices and platforms, enabling testers to test their applications across multiple devices and platforms. This ensures that applications are compatible with various IoT devices and platforms and perform reliably and consistently in various environments.

For instance, when creating an application that needs to run on multiple devices, it is possible to use an emulator to test the app on your laptop without setting up a development environment for each type of device.

IoT-enabled continuous testing provides real-time feedback on the performance and functionality of applications, enabling organizations to identify and address issues quickly and effectively.

Trends in Continuous Testing

Continuous testing is rapidly evolving to meet the needs of modern software development practices, with new trends emerging to address the challenges development teams face. Three key trends currently gaining traction in continuous testing are cloud-based testing, shift-left testing and security testing. These trends are driven by the need to increase efficiency and speed in software development while ensuring the highest quality and security levels. Let’s take a closer look at these trends.

Cloud-Based Testing: Continuous testing is deployed through cloud-based computing, which provides multiple benefits like ease of deployment, mobile accessibility and quick setup time. Businesses are now adopting cloud-based services due to their availability, flexibility and cost-effectiveness. Cloud-based testing doesn’t require coding skills or setup time, which makes it a popular choice for businesses.

AI-Driven Testing: AI-driven continuous testing is often integrated into cloud-based testing platforms, providing end-to-end automation for web, mobile and API testing. AI and cloud-based testing allows for access to testing environments anywhere, anytime, and provides for regular automated testing using platforms like Selenium.

Shift-Left Testing: Shift-left testing is software testing that involves testing earlier in the development cycle rather than waiting until later stages, such as system or acceptance testing. The goal of shift-left testing is to identify and address defects as early as possible.

Delaying testing until the end of development often results in more complicated bug fixes since the software is already fully built. This can cause an increase in cost and time to market. Identifying and fixing bugs earlier in the software development life cycle is generally more cost-effective.

As IBM’s Systems Sciences Institute claimed, repairing a bug discovered during implementation costs roughly six times more than one found during design. If a mistake is detected after product release, the cost of fixing it is four to five times greater than one found during design and up to 100 times greater than one found during the maintenance phase. This suggests that a bug’s cost increases exponentially as the software progresses through the SDLC.

Low-Code/No-Code: Low- or no-code in continuous testing refers to using visual interfaces and pre-built elements or modules to create and execute automated tests instead of writing complex code. Low-code/no-code testing tools often provide drag-and-drop interfaces and pre-built components that can be combined to create tests, reducing the time and effort required to develop and maintain test scripts.

This type of testing provides several advantages, such as allowing non-technical business experts to run testing, speeding up test production and execution and enhancing product quality by enabling more thorough and efficient testing.

Generally, according to statistics, by 2025, around 70% of new business applications are predicted to use low-code or no-code technologies.

Security Testing: Due to the rising incidence of cybersecurity threats and data breaches, security testing has become a crucial aspect of software quality assurance. In the year 2023, the tech world anticipates that there will be a stronger focus on security testing, with the emergence of more advanced tools and methodologies aimed at detecting and resolving security weaknesses in software applications.

June 6, 2023
How GitHub Actions Simplifies Your CI/CD Workflow

In today’s fast-paced world, being able to deploy applications quickly is essential for success. However, setting up a CI/CD pipeline can be a tedious and time-consuming task. Fortunately, GitHub Actions can help simplify and automate your workflow, making it easier than ever to get your applications up and running in no time. In this blog post, we’ll take a look at how to set up a React application with GitHub Actions and explore the benefits of using this tool for your CI/CD needs.

Continuous Integration and Continuous Deployment

Continuous integration (CI) and continuous deployment (CD) are essential components of any product development workflow. CI is the process of automatically building and testing code changes, while CD is the process of automatically deploying code changes to a production environment. Both CI and CD help to ensure that code changes are deployed quickly and efficiently, with minimal errors.

Setting up a CI/CD pipeline can be a tedious and time-consuming task, particularly if you are not familiar with the required tools and technologies. However, using GitHub Actions can help to simplify and automate your CI/CD workflow, making it easier and faster to deploy your code changes.

GitHub Actions is a powerful tool that can be used to automate many different tasks, including building, testing and deploying code changes. In addition, GitHub Actions can be used to trigger other actions in response to specific events, such as when a code change is pushed to a remote repository. This makes it an ideal tool for automating your CI/CD workflow.

There are many advantages to using GitHub Actions for CI/CD. First, it is easy to set up and use, even if you are not familiar with the underlying technology. Second, it integrates seamlessly with GitHub, making it easy to track and manage code changes. Finally, it is highly customizable, allowing you to tailor the automation process to meet your specific needs.

Setting up a React Application

React is a popular JavaScript library for building user interfaces. Setting up a React application is not complicated, but there are a few important steps you need to follow.

1. Choose your development environment. You can use create-react-app to set up a development environment with all the necessary dependencies and scripts.
2. Install React and ReactDOM. React is the library that handles rendering of UI components while ReactDOM takes care of interaction with the DOM.
3. Create a component file. In this file, you will write your UI code using JSX syntax.
4. Include the component file in your HTML page. Now you can see your component rendered on the page!

Development Mode and Production Mode

In software development, there are two primary modes that code can be run in: development mode and production mode. Development mode is typically used by developers when they are actively working on code. In this mode, code is usually not optimized and may include debugging features that help developers identify and fix errors. Production mode, on the other hand, is used when code is ready to be deployed to end-users. In production mode, code is typically optimized for performance and security.

One of the benefits of using GitHub Actions is that it makes it easy to manage both development and production workflows from a single platform. With GitHub Actions, you can create separate workflows for development and production, or you can create a single workflow that automatically detects whether code is being pushed to a development or production branch. This flexibility can simplify your CI/CD pipeline and help you avoid errors that can occur when manually managing multiple workflow files.

To learn more about how to use GitHub Actions to simplify your CI/CD pipeline, check out the following resources:
– [GitHub Actions documentation](https://help.github.com/en/articles/about-github-actions)
– [Tutorial: Use GitHub Actions to deploy a static website](https://help.github.com/en/articles/configuring-a-workflow#creating-a-workflow-file)
– [CI/CD with GitHub Actions blog post](https://blog.github.com/2019-08-08-introducing-github-actions/)

Setting up GitHub Actions

Setting up GitHub Actions is simple and only requires a few steps.

First, you’ll need to create a new file in your project’s root directory called “.github/workflows/ci.yml”. You can name this file whatever you like, but for the purposes of this article we’ll call it “ci.yml”.
In this file, you’ll need to specify the language your project is written in and the name of the action you want to run. For example, if your project is written in JavaScript and you want to run the “lint” action, your file would look like this:

name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v2
– name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}

Breakdown of the Actions File

In the “ci.yml” file, there are three main sections: “name”, “on”, and “jobs”. The “name” section is where you specify the name of your CI workflow. The “on” section is where you specify the events that will trigger your workflow to run. In this example, the workflow will run every time code is pushed to any branch. The “jobs” section is where you define the actual jobs that make up your workflow. In this example, there is only one job called “build”.

The “build” job has two steps. The first step checks out the code from GitHub. The second step runs a Node.js linter on the code to check for syntax errors. If any errors are found, they will be displayed in the GitHub UI.

You can also add additional jobs to your workflow, such as testing or deployment jobs. For example, you could add a job that automatically deploys your code to a staging environment whenever code is pushed to the development branch. This would allow you to test new features in a safe environment before deploying them to production.

Adding additional jobs can help simplify your CI/CD pipeline by automating more of the process. This can free up time for other tasks, such as writing documentation or working on other features.

Running the Action

Assuming you have already set up a workflow file (ci.yml) and added a job to it, running the workflow is simple. All you need to do is push some code to your GitHub repository and the workflow will automatically run.

You can also manually run a workflow by going to the Actions tab of your GitHub repository and clicking the “Run Workflow” button. This can be useful for debugging purposes or if you want to run a particular job without pushing code.

If you want to see the output of a workflow, you can go to the Jobs tab and click on the job that you want to see. This will show you the log output of the job as it ran.

March 2, 2023
Software Quality is the Heartbeat of the Best Organizations
JPMorgan recently announced it was hiring 2,000 engineers, despite the gloom in global economic markets. Is this not an odd risk for an organization to take, given the demand for (and cost of) software developers today? What’s happened?
JPMorgan’s hiring drive is no mystery. Virtually every company in the world is leveraging software, with many transforming themselves into software organizations to drive new efficiencies, widen profit margins and create new markets. Software has been disruptive, so much so that the current era has been dubbed the “third industrial revolution.” Consumers are benefiting from switching providers at the click of a few buttons and most consume services through software. Bad software experiences today mean rapid customer churn and competitive disadvantage.

Quality Should be the Heartbeat of any Organization

In spite of quality’s importance, testing is still perceived as a secondary discipline and a check-the-box exercise. This reflects practices developed for assembly lines during the original industrial revolution. A product gets assembled and testers verify its quality as it leaves the production line. Testing’s goal in this context was to identify problems before they reach end-users. This same approach has been applied widely to software development and is still used by “waterfall” organizations.

Yet, software development has been revolutionized by new methodologies and practices. Software today is constructed at incredible speed. Notice I’m using the word “constructed” and not “built”—the best developers leverage libraries or APIs to assemble software using existing components. They then add a few pieces of custom business logic to define the intellectual property of an application. Many organizations don’t even code software, instead customizing off-the-shelf software with vast configurations to modify functionality.

The assembly-line approach to software development is no longer appropriate. When testing is left late, defects are found before a release or even in production. Release cycles are longer and products poorer quality. Yet, many organizations still stick religiously to this approach, with testing teams operating in distinct silos.

The Role of the Tester is Evolving

The best organizations in the world are changing how software is built. Testing is no longer a check-the-box exercise at the end of the assembly line. It is transforming into a discipline that revolves around evangelizing and driving quality throughout an organization.

Quality should be baked in as early as possible, touching every artifact produced. Ideally, this should occur from the start, as a requirement is formulated, all the way through to the software being shipped. The idea of siloed teams working on different pieces is outdated. For quality to thrive, teams must collaborate.

Modeling offers one approach to driving quality and collaboration throughout an organization. Its journey starts with a requirement. These are typically formulated by business analysts or product owners. Having been a product owner, I found that this usually involves lots of scribbles on paper before communicating to stakeholders on a whiteboard. The preliminary requirement then gets reviewed and refined.

At some point, the requirement will be converted into walls of text in a project management tool. Modeling intervenes at this stage, adding visualizations that make requirements more consumable, less ambiguous and easier to understand.

The word “modeling” may seem a scary concept, but it need be no more than a flowchart that encapsulates a requirement. The benefit of modeling is not only that it provides a digital collaboration asset; models can also generate coverage-focused tests before a line of code is written. Modeling creates requirements that are quality-driven and quality-driving.

The Journey of Quality-Driven Requirements
- Models Provide Data Upfront
Developers today require rich data to develop, while testing is only as good as the available test data. Yet, many organizations still feed slices of production data into developers and test cases.
This approach is problematic for several reasons. First, it often risks legislative non-compliance. Second, production data features large volumes of low-variant data. Data may not then be available when developing unusual-but-important scenarios. Imagine an overdrawn account with several beneficiaries: What should happen when a transfer is attempted?

Modeling defines data explicitly in requirements. It allows engineers to understand a requirement explicitly, including the relevant data. From the modeled definitions, correct data can then be masked and subset, or generated synthetically. Data can further be delivered on-demand and at scale using database virtualization.
- Models Provide Understanding
Once the requirement and necessary data are available, code can be developed. Using text-based requirements, misinterpretations often lead to incorrect functionality. Visual models instead align closely with business logic, and we often see developers enriching models with additional context so that models align with the actual software implementation.
- Models Generate In-Sprint Tests
Once the code is developed, the same tests which were created earlier from the requirements can be executed against new functionality. This facilitates reuse and means the test cases are ready to be executed immediately.

Some tests might further be selected for automation. In this instance, automation can be overlaid onto the requirements model, reusing code to generate scripts. These scripts then become part of the standard regression pack as new features are added to the product.

A Change Request Comes In

With iterative development, change requests are common. This typically creates havoc for quality, since it is difficult to understand the impact of a change, and time-consuming to update artifacts like tests and data.

Traceability is key to overcoming this challenge. Models can connect to external DevOps tools to provide end-to-end traceability, from a requirement, all the way to code and tests. The impact of a change can then be identified directly. Models can be updated, automatically synchronizing test data, test cases, and automation to bring everything up to date.

Testing for the Fourth Industrial Revolution

Software is playing a vital role in virtually every organization, as already recognized by organizations thriving today. Baking quality in early is the only way to ensure quality software. The role of testing must change on a large scale. Models offer a way to achieve a “shift left” and collaborative approach to quality while testing earlier and more rigorously by automating and optimizing test and data creation.
October 27, 2022
CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

CloudBees announced today it has acquired ReleaseIQ, a provider of an orchestration platform for automating software delivery via a software-as-a-service (SaaS) platform.

Sacha Labourey, chief strategy officer for CloudBees, said the addition of ReleaseIQ to the CloudBees platform will provide more visibility into and control over software delivery on an end-to-end basis.

CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible.

The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations. That capability makes it much simpler to troubleshoot software deployments.

Labourey said that while ReleaseIQ can be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others, the primary focus will remain on the open source Jenkins platform that still owns the lion’s share of the DevOps market. The overall CloudBees goal remains to employ automation and remove as much friction as possible from DevOps workflows as part of an ongoing effort to improve developer productivity, he noted. CloudBees, however, regardless of the level of DevOps maturity within any organization, is committed to meeting customers where they are versus requiring them to rip and replace existing investments, Labourey added.

The overall level of DevOps maturity may vary widely both within and between organizations. However, as more organizations realize the extent to which they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD is fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction through which managing the pipelines that deliver software becomes simpler.

In general, most organizations are trying to strike some level of balance between centralizing the management of DevOps workflows and enabling development tools to adopt whatever tools they prefer. It’s not uncommon for application development teams to independently adopt any number of tools that ultimately need to be integrated with a DevOps toolchain. Each of those tools, however, contains metadata that needs to be shared with a centralized orchestration engine that automates a range of tasks across multiple pipelines based on the metadata collected from each tool.

There are, of course, still a lot of manual DevOps processes that should be automated. CloudBees is positioning ReleaseIQ as the orchestration engine for both unifying the management of pipelines and, ultimately. enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, a new foundation is being laid.

September 28, 2022
The Power of Automation and Distributed Sources of Truth

Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data–including most network configurations–is still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

The Source of Truth

More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if you’re going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesn’t currently exist. Given the multifarious nature of today’s networks, relying on a single source is both impractical and potentially expensive.

Rather than asking “What is the single source of truth?” perhaps the better question is “What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?”

Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

Cast a Wider Net

If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth won’t provide that.

Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

With the advent of programmable networks–machines talking to machines–the most current automation solutions can access multiple distributed sources of truth–different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

Automation Hesitation

So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process: “What if the data is only 70% accurate? If we try to automate with bad data, we’re going to break the network 30% of the time.”

Some network teams may believe they can’t automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a “pristine” database, they could lose months or even years of time, to the benefit of no one.

The solution is to take an incremental approach. Look at all the various network assets–programmable, cloud, legacy, etc.–and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

● API-first–The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
● Data federation and transformation–Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
● Unified view–An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

Multiple Sources Equal More Actionable Data

With today’s modern, programmable networks–and the absolute necessity for enterprises to have access to accurate, real-time network data–relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

August 29, 2022
The 6 Pillars of DevSecOps: Pillar One-Collective Responsibility
With the increased interest in DevSecOps, the Cloud Security Alliance (CSA) and Software Assurance Forum for Excellence in Code (SAFECode) brought together a DevSecOps Working Group to identify and share best practices for the development and maintenance of a DevSecOps program. This working group identified and defined six focus areas critical to integrating DevSecOps into an organization; this article will focus on pillar one⁠—collective responsibility

The Context of Security

When we look at security historically, we find that it has often been relegated as a secondary objective when compared to other primary objectives like releasing features to market quickly. The rationale is that if we don’t release fast, our competitors will get ahead of us. Unfortunately, that mindset is fraught with security risk as evidenced by the rising number of vulnerabilities in our software. Malicious actors can take advantage of these vulnerabilities to breach critical systems and exfiltrate sensitive data.

Let’s not be too hard on ourselves, however. Security in a DevOps world is not an easy problem to solve. As we continue patching vulnerable code, new flaws emerge just as quickly. In essence, the security landscape is dynamic and continues to evolve. Solving a complex problem like this requires diversity of thought. In other words, we need to include people with different perspectives in the security conversation. Essentially, we need to build a collective mindset rooted in security culture. Security then becomes a collective responsibility rather than the responsibility of a few people.

Now that we’ve agreed on the importance of collective responsibility, the logical question that emerges is, “How do I operationalize collective responsibility?” Pillar one addresses this question. We need to bring together our security and DevOps cultures. No longer can we talk about security or DevOps. It has to be both. This means security must be considered and addressed at every point in the software development and operations life cycles. Extending this further beyond the technical domain, security is fundamentally tied to business objectives, not left as an afterthought or considered a mere cost drain.

Building a security-supportive culture involves three broad phases:

Phase One: Gain executive support and engagement

Phase Two: Design an effective program

Phase Three: Sustain the program
What Does Pillar One Mean for DevSecOps Practices?

Pillar one reinforces the idea that security responsibility cannot be limited to a few people. Just as software development is no longer an exclusively technical activity, security is no longer a compliance activity. This has a profound impact on DevSecOps practices. Here are just a few areas that are impacted by this shift in mindset and responsibility:

People across software development and operations activities must now consider security requirements

Security tools can no longer run separately from DevOps pipelines

DevOps teams need to understand security and how it applies to their roles

Security teams need to translate high-level policies into clear, atomic security requirements that can be implemented and tested

How is Pillar One implemented?

Implementation of pillar one touches on structural issues aimed at removing silos. There are many possible ways to build cross-functional teams. One approach is to have security embedded inside DevOps teams. Another approach is to integrate security as a support structure for DevOps teams. In either case, given the limited number of security professionals, a security champion can help bridge the gap between DevOps teams and security teams. A security champion ensures that the software being built and deployed takes security into account. To achieve this, it is important to set up a security champion for success:

Security must be their primary responsibility

They must be viewed as the security expert in engineering teams

They are responsible for mentoring and training developers

They can own threat and privacy models

They must have clear goals that are aligned with the business

Setting up a security champions program without a clear sense of direction can lead to a lot of wasted time and effort. Collective responsibility rests on teams being able to communicate across functional silos and a security champion is an exemplar of that mindset.

Speed Versus Security

We live in a world where the rate of software development and deployment outpaces traditional security practices. This has come at a cost. Balancing both speed and security is the new norm. The right balance is dependent on each organization. One thing remains the same, however, and that is culture. We need a culture that is supportive of security and views it as a collective responsibility. This takes intentionality. Organizations need to get their executives involved and make sure the program has relevant elements to drive a security culture and has a clear path to business value.
April 6, 2022
All CloudBees (Approved and Proprietary) Tier 1 Plugins Support Configuration as Code

Plugin Configuration

So how do plugins come into this picture? As you may know Jenkins and CloudBees CI are largely the sum of the plugins that have been installed. A lot of these plugins come with their own configuration, which is used to customize their behavior or define what they integrate with.

Below is an example of a YAML configuration for the Kube Agent Management Plugin. This is a plugin which is used for configuring the Kubernetes Pod template for worker agents.

CloudBees has been working hard at delivering Configuration as Code (CasC) for CloudBees CI. A significant milestone has been reached this week with full support for all Tier 1 plugins for Configuration as Code. This key milestone coincides with Configuration as Code becoming generally available (GA) for CloudBees CI at the end of May. But before we talk about this milestone let’s first talk about what configuration as code is in general.

Configuration as Code Introduction

A key concept in cloud native DevOps is Everything as Code.

In the Everything as Code world that we live in now, you can use code-management tools to deal with complex things like configuring and customizing your applications and infrastructure. This allows you to make use of tools like version control, code comparison and replication for things that you would traditionally have to configure using a point-and-click user interface.

CloudBees CI and Jenkins are no exception to the Everything as Code model. As anyone who has set up a new Jenkins instance knows, this can be a detailed, time-consuming process, especially when you’re using the Manage Jenkins UI to do everything.

Configuration as code considerably simplifies the configuration of CloudBees CI. With configuration as code, you can turn complex configurations into easily-replicated, human-readable code files (YAML). You can manage those configuration files with source control tools like GitHub.

Tier 1 Plugin Support

Tier 1 plugins consist of both Verified & Proprietary plugins – 124 plugins to be exact. Enabling Configuration as Code support for all of them was a large undertaking but a necessary one as it made the management and governance of all them dramatically simpler. We also added test cases to make sure that future changes to the plugins don’t unexpectedly break configuration as code functionality.

Documentation for CloudBees CI Configuration as Code

Full documentation can be found here:

Link to Documentation for CloudBees CI Configuration as Code (Modern Platforms)

Link to Documentation CloudBees CI Configuration as Code (Traditional Platforms)

Documentation for Tier 1 Plugins Supporting Configuration as Code (Modern Platforms)

Documentation for Tier 1 Plugins Supporting Configuration as Code (Traditional Platforms)

Future Tier 2 Plugin Support

Currently, CloudBees does not support configuration as code for Tier 2 plugins. These are also referred to as Compatible Plugins. Out of the 112 Tier 2 plugins we have work planned to add support for Configuration as Code for 38 of these plugins. The remainder either do not require any configuration or already support configuration as code. The work to enable support for the Tier 2 plugins is planned for release in the fall of 2020. Tier 2 plugin enablement will be released piecemeal, so certain Tier 2 plugins will be released much earlier.

Community Credit

CloudBees CI Configuration as Code is built on top of open source Jenkins Configuration as Code. We would like to recognize all of the work which has been done in the open source community on this feature.

Any feedback or questions regarding CloudBees Configuration as Code in general or support of Tier 1 plugins is always welcome.

August 3, 2020
How IHG Puts DevOps Developers First

The following is a guest post by Robert Kelley, Director of Delivery Engineering at IHG, based on his session at CloudBees Connect. His full presentation is available below.

You may not necessarily recognize the company name IHG – the company I work for – but I bet you’ve heard of our brands and stayed in our hotels. They include household names like Holiday Inn, InterContinental, Crown Plaza and many more. IHG stands for the InterContinental Hotels Group and we’re one of the world’s largest hospitality groups in the world. IHG operates 6,000 hotels in more than 100 countries. And we’re growing fast: IHG currently has 1,900 hotels in the pipeline for opening.

It takes a lot of software to run a global operation of this size, especially one that’s growing so rapidly. IHG employs hundreds of engineers around the globe to build and deploy the business applications and systems that keep our company competitive and growing. As the director of delivery engineering at IHG, which is our DevOps program, I’m tasked with empowering these developers with the tools and processes they need to be productive and successful at their jobs, helping translate their work into business success for IHG.

That’s a tall order for any engineering organization and ours is no exception. But we’ve forged ahead on our DevOps journey, starting by putting together a business case and setting some high-level goals and ambitions for our teams. Our list includes adding more automation and certification to our delivery flows, improving our processes and gaining more transparency and visibility into performance. Of course, we want to support innovation to keep our business ahead of the competition.

After finalizing our goals, we “took them to market,” which in our case meant sharing them with the software development community here at IHG. What could go wrong, you might ask?

Well, right out of the gate we discovered there were significant differences among the teams, their cultures and their tools and processes. The disparity left us struggling to bridge the gap between where we wanted the teams to go, and where they thought they were going. This was going to be a tougher journey than we expected. We had to fail fast and learn quickly.

Rethinking standardization

It became clear we needed to rethink our approach and how we engaged our development community. Recognizing that one size doesn’t fit all, we decided to take more of a consultative or service mindset, focusing more on people and engaging our developer community. After all, we have a lot of smart developers with great ideas that represent an incredible value opportunity.

Our approach features a comprehensive communications plan designed to motivate developers to embrace DevOps. We’re looking at gamification strategies, for example, that would make it fun for people to engage with the program, share their accomplishments and track progress toward reaching their goals. We also want to help team members reduce the amount of time they need for build and deploy processes, so we’re introducing more automation, including developing a semiautomated onboarding process.

Moreover, we’re involving developers in a transparent governance process – one that’s not simply a rulebook handed down and controlled by a third party or some other group in the organization, but one that’s shared and co-developed by our teams. Everybody’s represented in the governance process. Teams from application development, testing and quality, infrastructure and operations, security – and of course the DevOps group – all have a voice and work together to define quality gates and other requirements. It’s a true “voice of the customer” approach that puts developers’ needs first.

Supporting developers

To tame the complexity of our environment, we’ve taken steps to achieve some consistency around things like testing, merge processes and build and deploy routines. However, we never want to hamstring developers by over-defining process flows, so instead we provide teams with simplified workflow or pipeline templates that should work for just about any application.

I’m proud to report that our teams have been making huge progress along our DevOps journey. We’ve helped build about 40 pipelines for dev teams and we’re working on even more. Performance is up: Teams are now able to move a new version of an application to production in less than 30 minutes, compared to taking a week previously. And it now takes less than two hours to deliver applications to eight datacenters worldwide, with no downtime.

We’re also tapping the insights of our developer community by creating an InnerSourcing model where virtually anybody who has a good idea can add it to our code base to benefit the whole organization.

This is just a small sampling of our recent successes. And it’s all happening without micromanaging our developer community. The way we look at it, we’re here to enable and guide our teams, not dictate their choice of tools and processes. By allowing for a diversity of approaches – by embracing not replacing – DevOps is empowering developers at IHG to unleash their creativity and help drive IHG’s next round of growth.

August 3, 2020
How to Do Agile Software Development the Right Way
Agile development has been around for years, but not everybody is doing it the right way. Just ask Elisabeth Hendrickson, who until recently was vice president of quality assurance at Pivotal Labs, a leader in agile software development and now a division of VMware.

Hendrickson’s career in the software industry spans a few decades and includes stints as a technical writer, developer, and test automation specialist. The variety of jobs has been a good thing, she says, giving her a holistic view of the industry and a deeper appreciation of each step of the development lifecycle.

Hendrickson started on her journey to agile software development after spending several years working for companies that developed software the traditional way, where the roles of code writing and quality testing were rigidly separated. She noticed that despite extensive testing, quality problems persisted. “It looked like QA was doing an incredible job,” she says. “They were finding and fixing all these bugs, so you think you would get better quality.”

Not so, Hendrickson says. “What’s happening is they’re finding the bugs so late in the cycle that it’s too late to fix them all.” Based on that experience, she wrote an award-winning paper debunking the notion that you can correct poor engineering simply by testing more.

In her search of a better way to do quality assurance, Hendrickson crossed paths with Rob Mee, co-founder of Pivotal Labs. “I had been learning about agile software development and I was intrigued by everything he said,” Hendrickson says. It wasn’t long before the future VP of QA joined Mee’s company. The move completely changed her perspective. “This is what software development is supposed to feel like,” she recalls thinking. “I never looked back.”

Agile Creativity

At Pivotal, she came to realize that agile software development was all about getting ideas into the code base in a way that was quickly “shippable,” thus allowing for fast feedback. She saw how waterfall-type approaches, with their multiple stages and signoffs, were actually just a series bottlenecks that slowed innovation. By contrast, agile software development – when done correctly – smooths the path from innovation to delivery. Agile practices were there to support human creativity, not about “process for process’ sake.”

Although organizations have now widely embraced the concept of agile software development, Hendrickson believes one of agile’s core tenets – early feedback – has been forgotten by many, with potentially dire consequences. “Agile done badly can be dangerous,” she says. “If you don’t have any form of feedback and you’re just focusing on being fast, you will end up shipping software that doesn’t work.”

How do you know you’re doing agile right? Hendrickson boils it down to what she calls the “Agile Acid Test.” There are three parts to it:

Delivering a continuous stream of value. This doesn’t mean developing faster, but rather sooner. You put capabilities into the hands of customers more frequently, in smaller chunks, and get feedback faster.

At a sustainable pace. Delivering software more frequently doesn’t work if it’s not sustainable for the team. “Doing a death march every month doesn’t work,” Hendrickson says.

While adapting to the changing needs of the business. As the world shifts, your organization needs to shift with it. Agile software development makes sure you don’t build software products that nobody wants.

Delivering software continuously at a sustainable pace enables you to get the feedback you need to “steer towards value,” Hendrickson says. That’s why she’s always focused on delivering sooner, not faster. And when you think about it more broadly, she says, that’s a strategy that could benefit the whole business.

What else is on Elisabeth Hendrickson’s mind? Tune into DevOps Radio Episode #75 to learn about how she motivates development teams, thrives in a traditionally male industry, and avoids one of the worst mistakes you can make in agile software development.
August 3, 2020