devopsy.kinsta.cloud

Category: CloudBees

  • Why DevOps is Key to Software Supply Chain Security

    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.

  • Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Today, some of the biggest government programs in existence are Medicare and Medicaid with the two health care insurance providers serving over 43% of the U.S. population. The Centers for Medicare and Medicaid (CMS) spent $1.6 trillion in 2021 and continue to grow in both size and cost on an annual basis. With this type of investment and permeation into the American populace, one would assume that this program would be running on the most up-to-date applications available. However, both public and private health care insurance carriers continue to operate on legacy systems.

    Recently, Andrea Fletcher, the digital services director of the CMS, described their system as operating on technology from the 1960s, which is alarming considering the responsibilities of the program. In fact, the Biden administration has only recently announced plans to modernize their organ matching system. This announcement came from a study conducted in February, which showed that only 26% of organs were procured from donors on average. This is just one example of how efforts to improve legacy systems, which are currently being used by over 40% of the population, allow both public and private organizations to operate in a more efficient manner as well as satisfy user needs. Further exploration will show how modernization improves other areas of business, such as creating user experiences that are both easier to navigate and more personalized as well as the ability to incorporate the latest cybersecurity updates.

    Modernizing as a Means to Improve User Accessibility and Personalization

    Given the size and diversity of the United States population, a modern flexible system is necessary for creating a smooth user experience for every individual. Today, users connect with insurance carriers using a variety of different devices while communicating using different languages and possessing different levels of technical expertise. The ability to create a personalized user experience for each individual will require a level of modernization that legacy systems were not built for. The importance of this flexibility is accentuated when considering that the purpose of Medicare and Medicaid, in particular, is to serve the elderly and underprivileged.

    Prioritizing the modernization of the consumer experience is not limited to just government organizations. In an independent survey conducted by Evolveware, 46% of private organizations measure the success of their application modernization efforts through an expected improvement in customer experience. As health care insurers continue to rely more heavily on analytics and the population continues to adopt digital technologies, the process of creating a streamlined and targeted approach to purchasing and managing health care becomes essential to staying competitive. For a multitude of companies in the marketplace, having an agile system that can be customized to each individual user can be a major differentiator, especially given the variety of factors that each individual has when it comes to making decisions about their health. Moreover, by prioritizing the user experience, organizations can improve their brand loyalty and customer retention, which are key factors when dealing with a competitive marketplace with a lot of players. Insurers have recognized this, as a recent survey of CIOs by Gartner showed that improving the customer experience and application modernization were listed as the highest priorities in the insurance industry. As customers become more judicious with their money due to current macroeconomic trends, providers will need to make sure their platforms’ user experiences are on par with their competitors.

    Modernization to Mitigate the Impact of Hidden Costs and Security Vulnerabilities

    The costs of not updating legacy systems should also be taken into consideration when making the decision to modernize. While the expense and process of moving away from legacy systems can seem like a significant obstacle, these systems, due to on-site maintenance and operational costs, are already expensive to maintain on a continuous basis. In fact, health care IT teams spend around 60% of their time trying to maintain and manage legacy systems. Furthermore, the opportunity cost of IT teams focusing on maintenance over innovation is significant, especially given the potential of the latest technologies to deliver a more intuitive user experience. There is also an understated but pressing labor cost with legacy systems, as members of the workforce who are familiar with these systems are aging and retiring, and the replacement workforce is not well-versed in legacy languages and technologies.

    Finally, legacy systems can also contain blind spots that are prime targets for cybersecurity breaches and hacks today. Legacy applications were built at a time when these types of attacks were not common and, therefore, don’t have the most up-to-date security capabilities embedded. Many of these systems also do not have up-to-date documentation, resulting in a high potential for hidden vulnerabilities. For health care organizations that have access to sensitive data, understanding and then shoring up these vulnerabilities using modern security features is critical.

    Health Care Modernization Example: Chatbots

    One prominent example of how application modernization can lead to organizational success is the integration of chatbots. As technology expands and businesses identify new ways to reach consumers, the addition of chatbots has become more prominent on platforms across industries. For the health care insurance industry, the bots provide both a cost-efficient way to process insurance claims as well as an enhanced user experience through ease of use. Recent estimations show that bots can handle the workload of two to five claims processors and can deliver 20 times the production relative to cost, allowing industry employees to focus on less tedious and more innovative tasks. Using generative AI models, chatbots will continue to become more sophisticated and varied in their responses to user input. As a result, modernizing legacy systems to optimize the integration of these bots becomes integral to remaining competitive in the marketplace.

    Legacy Systems and the Future

    As we look to the future, both government and private insurance carriers have plenty of internal and external factors that incentivize application modernization. As Medicare and Medicaid continue to grow due to the increasing number of eligible users, an agile system is integral for user accessibility. Meanwhile, macroeconomic factors such as high costs and an increasingly competitive marketplace will force private organizations to adopt systems that can integrate and adapt to the newest technologies for a better and more secure customer experience. With serious challenges facing both the public and private sectors of healthcare insurance, the necessity to modernize has never been greater.

  • The Future of Continuous Testing in CI/CD

    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.

  • How GitHub Actions Simplifies Your CI/CD Workflow

    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.

  • Software Quality is the Heartbeat of the Best Organizations

    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.

  • Business Leaders Will Trade Speed for Security

    Business Leaders Will Trade Speed for Security

    A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

    As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

    Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

    Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

    CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

    Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

    The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

    As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

    Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

  • CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    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.

  • DevOps World 2022: A DevOps Retrospective

    DevOps World 2022: A DevOps Retrospective

    With the seminal IT conference DevOps World 2022 in Orlando September 26 to September 29 upon us, I think about the pivotal industry conferences and events critical to my path to the cloud, DevOps and cloud-native. It brings me to this brief retrospective, highlighting some of the most significant influences that still guide my path today.

    I highlight these for you as conferences, books, emerging development tools, and changes in infrastructure delivery all played critical roles in my completely rethinking of how we create software through DevOps.While leading IT for a global R&D industry consortium from 2010 to 2016, I was unknowingly in the middle of a significant shift from designing network protocols to entirely moving to the cloud, creating self-service development portals and automating the development process.

    This journey began partly when a friend and colleague, Alan Shimel, creator of the then-new devopsy.kinsta.cloud site, said, “Check out this thing called DevOps … and you gotta read this book!” Looking back at my Amazon order history, I see I first purchased The Phoenix Project in November 2013. The book immediately became the main topic of discussion among my engineering team. While we didn’t label it as a DevOps tool then, Jenkins established the basis of our DevOps toolchain across multiple software-based research projects. Other technologies, including Artifactory, Maven, Git, GitHub, Bamboo and OpenShift, for example, quickly followed, enabling us to spin up development environments for many new software projects. In less than a year, we completely retooled IT from a significant bottleneck to becoming the easiest path to creating new software projects by equipping teams with DevOps, development tools, environments and cloud platforms.

    Jenkins World (now DevOps World) helped me understand the central roles CI and CD played in creating automated workflows and delivering software more quickly from development into test environments. The first AWS re:Invent helped me rethink the cloud, from a data center scarcity mindset to making compute, storage and bandwidth resources harnessed through automation and a credit card. I wrote my first post about DevOps in 2014, The DevOps Journey, where I did my best to make sense of precisely what DevOps is.

    As I go back and reread that post, I’m surprised how much of those thoughts still apply in 2022. Today, I continuously read many technical books, learn from thought leaders and attend influential conferences, including this year’s DevOps World. I wonder what will change how we think about and create software again in the next decade!

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!

     

  • What a Dev Wants: Security Training for Today’s Developer Workforce

    What a Dev Wants: Security Training for Today’s Developer Workforce

    It’s no secret that developing a strong security culture is a critical component of the production of secure products, yet organizations often overlook the fact that their security training programs set the foundation on which this culture is built. When it comes to developer training, our goal should be to align the intrinsic motivations of a learner with the company’s strategy and objectives. But if either of these is misaligned, the training program, and ultimately the organization, will suffer because it is either irrelevant or perceived as a compulsory box that needs to be checked.

    Addressing the Interests of Developers Vs. the Organization

    Unfortunately, there is a gap between the buyer persona and the developers themselves, even though developers tend to have a fairly consistent response about the ways they want to be trained. Rather than implement a program that is doomed to be viewed as a time-consuming compliance requisite, organizations should rather ask this simple, yet pertinent question: What do developers really want out of their security training program?

    When it comes to today’s security training programs for developers, there’s often a separation between compliance-based training and developer-centric training; in other words, the interests of the organization don’t always align with the interests of the developers. In most highly regulated organizations, there is a mandated security training curriculum that all employees, including the development teams, are required to go through on a yearly basis. This leads to a drawn-out, painful process that leaves employees clicking through modules as fast as possible. Developers may then need to go back and look up security topics on a regular basis if they are looking to implement them into their code.

    While developers are certainly making an effort to adhere to security requirements, this greatly slows the ability to get the product to market in a secure and efficient way.

    What Training do Developers Really Want?

    Organizations should prioritize programs that will specifically target their development teams by asking what those developers are actually looking for. With so many training programs on the market, it can be difficult for an organization to determine which will resonate the most with their employees, specifically their development teams. The fact of the matter is that, when it comes to security training, the majority of developers want to do as little of it as possible. They are willing to check the boxes for compliance purposes, but they want it to be as seamless as possible. As the complexity of training tactics continues to evolve, an ideal curriculum is simple, like programs that can be embedded in the tools developers use on a daily basis.

    The most effective training programs are engaging and relevant. Managers tend to see better results from training that is hands-on, interactive, engaging and related to developer tasks. Gamification is also a great way to engage developers. For instance, organizations have started livening up their training curriculum with leaderboards. In fact, recent studies have indicated that developers would opt into shared company leaderboards with points for content consumed. Not only are these programs engaging for the developers, but they are also incredibly effective, as they motivate teams to view more content by leveraging individuals’ pure competitive drive.

    Security Champion Programs for the Win

    Organizations could also implement a security champions program. These programs vary depending on the organization, but in its simplest form, a security champions program designates a “champion” from each team. The champion is then tasked with leading the team as a subject matter expert as far as security goes. One thing to keep in mind here is that this program could be a major failure if done improperly. Remember, you don’t want to designate just anyone as the team security champion; you want to be sure you’re selecting an engaged employee that will prioritize secure practices and proactively communicate updates across the team.

    Regardless of what avenue an organization chooses, the name of the game is ensuring development teams are actively engaged with a relevant and realistic training program. The result of which will have an important downstream impact as organizations work to build a culture with a strong foundation in security. After all, “checking the box” can only go so far when it comes to developing a winning—and secure—solution.