devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

The Surprising Secret to DevOps ROI

As a result of my many years of DevOps consulting, I have discovered a simple, but not well-understood, secret ingredient that drives ROI for all the Three Ways of DevOps.

Measuring and optimizing return on investment (ROI) for DevOps is not well-understood. It is a proven fact that DevOps, when engineered well, delivers tremendous value to organizations by way of continuous delivery practices. Reduced lead time, more frequent releases, lower failure rates and faster time to restore services are well-accepted indicators of DevOps value. It is not a secret that the combination of engineering DevOps practices for people, processes, and technologies around the Three Ways of DevOps – continuous flow, continuous feedback and continuous improvement – gets results. As valuable as these things are, they are not a measure of ROI, and do not tell you what to do to improve the return on your DevOps investments.

How Do You Calculate and Optimize DevOps ROI?

First, it is important to understand that ROI for DevOps is best measured using a simple ratio of return (R) divided by investment (I). (OK – for the accounting purists out there; I know the real ROI formula is actually (((R-I)/I)*100%) but that is a technicality that we don’t need for this argument.)

The “return” of DevOps value is the important factor in the numerator of the ROI ratio. While there are many values that can be attributed to DevOps, the most direct value that can be measured and justified for legitimate comparison purposes is the cost savings associated with accelerating software delivery value streams. Application developers, and others, can get more applications released faster because of DevOps, which has a dramatic effect on valuable cost reductions. The “investment” in DevOps projects is the denominator of the ROI ratio. To optimize ROI, simply increase return by getting more application releases out faster, while reducing the investment required for a DevOps project. Sounds easy enough. But wait! How do you do that?

The primary factor in the return is derived from reducing bottlenecks. I have found, in more than half of the thousands of DevOps value streams I’ve studied, that the biggest bottleneck is testing! It is a myth that continuous testing is just the execution of automated tests. I am talking about the whole range of ‘testing things,’ including test strategy, test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, fix, retest and test management. That is a lot! In fact, testing things are a source of bottlenecks for every stage of a DevOps pipeline, for all three ways of DevOps. The point is that ROI can be greatly improved by improving testing.

As it turns out, the primary factor in reducing investment costs also has to do with testing! Putting ‘testing things’ in place is expensive in terms of labor and capital costs for both people and systems. The primary factor to reduce total investment cost is to standardize, share and use ‘testing things’ with as many application pipelines and stages as possible.

What is the secret ingredient that I have discovered? After all, the importance of testing itself is not much of a secret. I have isolated the key ingredient that is the heart of all ‘testing things.’ The purpose of a test is to determine a verdict. A test verdict is the codified representation of a pass, fail or inconclusive result state of a test, assessed relative to the purpose of the test. Test verdicts are essential, no matter what kind of test it is; no matter the stage in the pipeline a test is used. Without a verdict, all the ‘testing things’ in the world are not valuable.

So – the secret ingredient for optimizing DevOps ROI is to optimize test verdicts. Those that know how to optimize test verdicts hold the key to optimizing DevOps ROI.

As I indicated in this eBook I authored for the DevOps Institute, verdicts from properly engineered testing at each stage in the pipeline are essential for assessing the artifacts produced in each stage.

How Can You Optimize Test Verdicts?

As I have pointed out in prior articles, well-engineered DevOps requires balancing the nine pillars of DevOps.
Surprisingly, test verdicts play a crucial role in optimizing all nine pillars of DevOps, and are vital to accomplishing the best return for the least cost investment in DevOps. Here are some examples of how this works for each pillar:

Leadership – Leaders tend to underestimate the importance that ‘testing things’ have on DevOps ROI, and that the central ingredient of test effectiveness is the optimization of test verdicts. By sponsoring DevOps projects and training programs that drive improved test verdicts, leaders will have a direct and lasting impact on ROI.

Collaborative Culture – How often have you seen people wasting time arguing over the meaning and importance of a test? Collaboration between application developers and QA and Ops teams is more effective when test verdicts are clear and based on a common understanding of the purpose and importance of each test.

Design – The creation of excellent tests, designed to efficiently resolve to clear verdicts during the design phase, makes for reusable test assets in all subsequent stages and releases, and can be reused with other applications.

Continuous Integration – The validation of builds is faster when all integration tests are arranged to get clear verdicts quickly during the build process.

Continuous Testing – Test verdicts associated with each test are the key information ingredient that test management systems can key off to optimize test selection and test execution for each stage in the continuous delivery pipeline.

Elastic Infrastructure – Test environment management (TEM) systems can optimize the orchestration of test resources better when test verdicts are clearly understood. Knowing a history of verdicts for a group of tests indicate which resources and how much of each resource are needed to run each test. This knowledge is essential to drive test environment management systems that have scaling algorithms for optimizing the use of ephemeral test environments, and to ensure test resources are used optimally.

Continuous Monitoring – Reporting and analysis of test results can be a major bottleneck in the pipeline, but can be dramatically accelerated when the test verdicts are clearly defined.

Continuous Security – Security tests are not much use without a clear verdict. While there is no such thing as 100% security assurance, the aggregate set of security test verdicts helps to profile security for applications and releases.

Continuous Delivery – Algorithms that govern the ‘doneness’ of an application release candidate, and decisions to promote a release to production, depend on analysis of service level objectives (SLOs) derived from service level indicators (SLIs), including test verdicts. The fidelity and quality of those verdicts is essential for operations and site reliability engineering (SRE) teams to be confident enough to not bottleneck an application release.

What This Means

Measuring and optimizing DevOps ROI requires strategies that deliver value by improving returns through reducing bottlenecks and reducing investment costs. ‘Testing things’ are a dominant factor contributing dramatically to both the return and investment components of the ROI equation. A comprehensive strategy for optimizing test verdicts is the secret ingredient for optimizing and leveraging investment in ‘testing things,’ which, in turn, has a dramatic effect on improving DevOps ROI.

March 31, 2021
Tricentis Aquires Neotys to Gain Load Testing Tools

Tricentis announced today it has acquired Neotys as part of an effort to expand the scope of its tools portfolio into the realm of load testing. Terms of the deal were not disclosed.

Neotys provides application testing teams with automatic test design and maintenance, user behavior simulation and root cause analysis capabilities using a set of tools that are designed to be integrated within a DevOps toolchain.

Sandeep Johri, Tricentis CEO, said the Neotys platform will extend the scope of Tricentis’ Tosca testing platform that today enables DevOps teams to employ machine learning algorithms to test the functions within an application.

In general, Johri said there’s now a lot more focus on load testing, thanks in part to the rise of microservices-based applications that are starting to be deployed at scale. DevOps teams are, first, trying to identify, as early as possible, a single point of failure that might bring down an application. Second, modern microservices-based applications are designed to degrade gracefully when there is no single point of failure. Identifying what issues are leading to that degradation can be challenging, given all the dependencies that might exist within a microservices-based application.

Neotys claims to have more than 600 enterprise customers, including BNP Paribas, Dell, Lufthansa, McKesson and Verizon. Tricentis claims to have more than 1,800 customers, including McKesson, Accenture, Nationwide Insurance, Allianz, Telstra, Rockwell Automation, Moët Hennessy-Louis Vuitton (LVMH PCIS) and Vodafone. The acquisition of Neotys will reduce the number of vendors that an organization needs to engage to gain access to a portfolio of testing tools, Johri noted.

As IT organizations embrace DevOps best practices, more responsibility for application testing is clearly shifting left toward developers. However, it’s not quite clear to what degree that shift is either eliminating or reducing the need for dedicated application testing teams at the back end of the application development process.

At the same time, many rote testing tasks are now being automated using machine learning algorithms. Those algorithms don’t completely eliminate the need for humans to test applications, but they do significantly reduce the testing time required. They should also create more time for developers to collaborate with one another to review more complex interactions within an application that machine learning algorithms are unlikely to be able to automate any time soon.

The amount of time organizations devote to application testing has always been constrained. As deployment deadlines approach, often the first thing that gets reduced is the amount of time allocated to application testing. In many cases, developers deliberately don’t address some known issues until the first or second update to an application that has already been deployed in a production environment.

Of course, integrating application testing within a DevOps process enables organizations to identify more potential issues earlier when they are easier and less expensive to fix. The challenge has always been getting developers to appreciate the value of testing early and often in the application development process.

Regardless of how application testing continues to evolve in the age of DevOps the one thing that is certain is no matter how automated it gets developers are going to be more involved than ever.

March 30, 2021
App Testing Must Evolve Within the DevOps Pipeline

As the practice of DevOps evolves, so do the supporting tasks; hopefully in such a way that they introduce increased efficiency and automation to accelerate development and deployment pipelines. However, one specific process still remains a speed bump on the road to DevOps acceleration: the process—or, more specifically, the chore—of testing.

Naturally, testing is an undeniably important component of quality assurance. However, introducing efficiency into a process that dictates quality assurance can accelerate development and improve outcomes, especially when it comes to application testing.

“Application testing should never be done in a vacuum, or, worse, a silo,” said Sara Faatz director, developer relations at Progress Software. “The DevOps process can benefit from accelerating the testing process, introducing automation and embracing teamwork.”

Faatz makes some valid points; historically, application testing was treated as either a standalone or separate process, and often was performed by non-programmers following some type of script. “We discovered early on that creating synergy between testers and developers was an important concept for accelerating development, while fostering teamwork,” said Ramiro Millan, director, product development, Test Studio. “Addressing the trifecta of acceleration, automation and teamwork challenges actually requires adopting a different mindset when it comes to testing, especially when it comes to automation and communication.”

However, solving those problems requires adopting different procedures, as well as deploying tools to streamline processes and introduce automation. That said, there are ancillary challenges that also have to be addressed. For example, there is often a disconnect between the cultures of QA teams and development teams. Here, QA teams need to overhaul their processes and introduce more agile practices. In other words, the time is now to identify new practices and methods that allow QA teams to be creative and innovative while helping to test the software created by DevOps.

“Automation is becoming hyper-critical for testing. However, it is not just automation alone, but also the ability to run tests in the background and not hijack control of the console or the machine,” Millan said. “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.”

That makes a great deal of sense. In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.

“Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times,” Faatz said. “The ultimate goal here is to bring forth faster delivery, less maintenance and more stability. I think stability is a big part of the equation. If we can automate those day-to-day, repetitive tasks, we garner that additional stability.”

Although testing is a broad subject, many of the lessons offered can have a beneficial impact on the overall process. Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on. This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process.

“The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation,” Millan said. “Automation brings about consistency, and consistency brings forth improved results.”

The lessons learned indicate that testing must evolve to keep up with the DevOps model, and also suggest that DevOps is pushing QA teams to adopt new methods of testing and interaction. The only remaining question is how quickly QA can better integrate into DevOps, and eliminate the deployment speed bumps.

March 19, 2021
Why Developers Should Care About Resilience

Recently, a friend reminded me of a joke we used to have when we were both developers at a huge software corporation (we won’t mention names, but back when printers were a thing, you probably owned one of theirs). We didn’t develop printers. We developed performance testing and monitoring tools.

We were the dev team, which was completely separate from the QA team and from the Ops team (yes, I’m that old – we didn’t even call it DevOps back then). Support was part of a completely different organization and “business” was something that happened in an altogether different galaxy. That is, until a customer had an issue.

When an important customer had an issue, we definitely felt it at R&D. Managers called hourly to check on status, and we would have intense conversations with the support team who would then, in turn, have intense discussions with the customer. If we, the software engineers developing the product, ended up on the same call with both support and the customer, it was a sure sign that things were bad. You knew that millions of dollars were on the line, and, consequently, that pressure was high. But most of all: you knew that we would do anything we could to solve the problem, because we needed those millions of dollars to be paid, so that we could keep getting paid. And so, we kept the coffee flowing.

This is where the joke part comes in. We used to have a system for managing support tickets, collecting information, tracking time and assigning it to the relevant software or support engineer, so everyone would know who was in charge. Today, you probably use Zendesk, ServiceNow or one of their alternatives. We used a home grown system, of course.

Our joke was this: the purpose of the system was not to track and measure and propagate the handling of customer issues. The purpose of the system was to indicate someone else is now responsible for solving the problem. Or, if you would rather paraphrase one of my favorite Douglas Adams jokes, the issue is now under a Somebody Else’s Problem field.

Because solving customer issues is difficult and frustrating, and being pressured by business could ruin a software engineer’s day. This is because when you’re a happy code monkey, and all you want to worry about is writing beautiful code and releasing cool features and drinking some coffee, solving a customer issue gets in your way.

You end up spending too much time sifting through endless logs, crossing your fingers and trying to reproduce an issue that only happens at 2 a.m. on a Friday, usually when a blue zebra is passing by. Spending your time on a heated support call is less fun than, say, drinking coffee quietly with your friends.

As R&D managers, we understand that our developers want nothing to do with solving customer issues. We want to make sure they are motivated and happy and efficient, and that they are free to challenge themselves by learning the latest buzz-worthy technologies and thinking up ways to introduce those into our product in a way that will make our customers happy.

Additionally, as R&D managers, we are far more likely to understand the business impact of having too many support tickets or having support tickets that take too long to resolve. We know that the loss on such cases is twofold:

1. The customer that faced an issue and is waiting for a solution may become frustrated, and the company may lose their business.
2. Our engineers are busy solving that customer issue instead of delivering new value to the business.

Therefore, as R&D managers, it is our responsibility to make sure that our engineers have the tools to handle these issues as efficiently as possible when they come up. It is our responsibility to make sure they are motivated, and that they understand the business impact of solving a customer issue as quickly as possible. And whenever possible, it is our job to make sure that they make our application as reliable and stable as possible to begin with.

That ensures that we have test coverage, and the right knowledge, practices and tools to ensure that we have as few customer issues as possible to begin with.

Happily, changes in dev culture usually means that “support” and “business” and even “customers” are not as far away as they used to be. When developing a SaaS platform, your developers often have an almost intimate, real-time ability to track what users are doing and how it impacts their experience. The culture of DevOps has done a lot for breaking the silos that used to separate the dev team from the support team, and to make sure that all members of the team engage and understand how the code they write and the issues they resolve help our customers.

I hope you already found the way to motivate your team to solve such issues, and that they have enough time to drink coffee. If you and your team are still struggling, we suggest bringing in a live debugging tool that can help them solve customer issues even faster, by making sure they have all the data they need at their fingertips, and that they can instantly reproduce any issue in a live, remote environment. Live debugging tools give your engineers a developer-friendly experience, and also gives them the power to reduce issue resolution time, too. Now, all you need to worry about is that your engineers have enough coffee.

March 17, 2021
Oracle Updates Java Development Platform

Oracle announced today the availability of Java 16, which adds 17 enhancements to a software development kit that is now being updated every six months.

Georges Saab, vice president of development for the Java Platform Group at Oracle, said while most Java development teams are still using Java 8 or earlier editions of the platform, the expectation is that many of them will soon move forward, as updates are made available in smaller increments that are easier to test and vet.

At the same time, Oracle is committing to make available long term release editions of Java that won’t be updated as frequently. While there are many organizations anxious to take advantage of new capabilities as quickly as possible, Saab noted there are just as many that value stability more than innovation.

The latest edition adds support for finalized pattern matching for instances and records, as well as other language enhancements that were previewed in Java 14. Developers can also employ a packaging tool to ship self-contained Java applications that will make it easier to deploy in modern IT environments, said Saab.

Additional capabilities now available include the Vector application programming interface (API), the Foreign Linker API (JEP 389), and the Foreign-Memory Access API that are all available in incubations as well as a sealed classes capability that is being made available as a preview.

In general, Saab said, one of the primary reasons many organizations don’t tend to update Java more frequently is the frameworks they rely on to employ it at a higher level of abstraction are still optimized for older versions. However, as Java updates are delivered in a more modular fashion, it will become easier for the providers of those frameworks to keep pace.

It’s not precisely clear to what degree IT teams are employing Java to build next-generation applications based on microservices. However, a recent survey published by VMware, found 95% of respondents have either already used the open source Spring framework, based on Java, to either containerize an application (65%) or plan to do so (30%).

A quarter of a century after its initial development, Java is still the dominant programming language relied on to build enterprise applications. In many instances, the lack of tools for building Java applications for Kubernetes platforms was a significant inhibitor of adoption for the cloud-native platform. In the last six months, however, the number of tools for building and deploying Java applications on Kubernetes clusters has increased.

Despite the proliferation of alternative platforms for building and deploying applications on Kubernetes platforms, the appetite for retraining legions of Java developers is low. Most developers will rely on the programming tool they already know, especially when it comes to building mission-critical applications for the enterprise. That may mean some of those applications might not be as fast as they could be, but, given the level of risk, there’s always going to be a natural tendency toward being safe rather than sorry.

March 16, 2021
Sonatype Acquires MuseDev to Add Code Analysis

Sonatype today revealed it has acquired MuseDev, a provider of a code analysis tool, in addition to updating its Nexus platform for discovering vulnerabilities in software supply chains.

Muse analyzes code each time a pull request is made, which makes it easier for developers to discover and address issues long before they commit code. Muse is integrated with 24 pre-configured code analyzers for GitHub, GitLab and Bitbucket repositories. It then analyzes each pull request to surface bugs, as part of automated code review, and includes analysis of interprocedural information flow and thread safety issue analysis, along with guidance to fix any bugs discovered.

In addition to adding support for Muse, the latest edition of the Nexus platform integrates a container firewall from NueVector along with a set of tools for identifying and providing guidance on how to address misconfiguration issues that frequently arise when developers employ open source Terraform software to programmatically manage infrastructure as code.

Finally, Sonatype added tools to provide better guidance on the implications of open source licensing terms attached to various projects, while at the same time starting its own community for organizations migrating from Bintray and JCenter, now that those tools have been sunsetted.

Brian Fox, Sonatype CTO, said the expectation is Muse will create an opportunity to introduce the complete DevSecOps portfolio to developers as they analyze code. Most developers are keenly interested in both optimizing and securing their code. They would just prefer to achieve that goal on their own versus being informed of an issue after code has been committed to a repository managed by a larger DevOps team, noted Fox.

An advanced development pack was added to the Nexus platform last year to make it easier to surface dependencies in code that are vulnerable to threats. It applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injections. Collectively, these tools give developers control over third-party open source code, first-party source code, infrastructure as code and containerized code, Fox said.

Sonatype claims it now counts 70% of the Fortune 100 as customers, and supports more than 2,000 commercial engineering teams. In 2020, it claimed it saw a 35% annual growth in Nexus repository installs, which now stands at more than 250,000 instances employed by nearly 15 million developers.

Overall, it’s not clear how much progress is being made toward embracing DevSecOps best practices. Sonatype, however. is making a case for putting DevSecOps tools directly into the hands of developers to address software supply chain security. In the wake of some recent high-profile breaches involving software supply chains, that approach may soon gain additional traction. After all, for all the encouragement being provided by application development team leaders these days, there’s nothing quite as effective as providing developers with a set of tools that enables them to achieve that goal on their own terms versus requiring them to follow a set of procedures dictated by a DevOps management team.

March 16, 2021
How AI Will Drive Digital Twin 3.0
Testing is a critical task for digital twins, and AI will increase the efficacy of the testing model moving forward

Physics calculations may work perfectly well in theory. On a blackboard, academic science is pretty predictable (outside of the quantum realm, perhaps). Yet, nothing is manufactured in a complete vacuum, is it? When it comes to real-world settings, millions of factors could impact the state of a physical object — material, friction, temperature, pressure, altitude, wear… the list goes on.

With so many tangible conditions increasing the likelihood of deviation, it can be difficult to reproduce a digital twin that accurately represents real-world conditions. This is, in part, why some believe the next generation of digital twins will be more driven by artificial intelligence (AI). By leveraging neural networks created with sensor data, production could trust intelligence gathered from trends across data points instead of solely relying on theoretical models. This could enable better predictability, optimized operational performances and overall improved products.

To discover what the next generation of digital twins will look like, I recently met with Faustino Gomez, co-founder and CEO of NNAISENSE. Below, we’ll define what a digital twin is and why the concept needs an upgrade. We’ll also explore a few digital twin use cases to see how the next wave of AI-driven digital twins will be “learning directly from the data,” as Gomez describes.

What Is a Digital Twin?

No, we’re not discussing your cyber clone. Digital twins are a bit less transhuman than that. Put simply, a digital twin is a digital duplicate of a physical object or system. Digital twins are commonly used across many industries to monitor and test intricate apparatus. Industrial manufacturing, for example, often leverages a digital twin to monitor production and test the performance of equipment within a simulated environment.

Digital Twin 1.0

Some of the first digital twins are attributed to NASA. By reproducing mechanical objects locally, NASA could diagnose issues and test solutions for physical components 200,000 miles away in space, far beyond direct human intervention.

The digital twin concept also found roots in other mechanical devices, such as jet engines, enabling on-the-ground mechanics to diagnose issues in the air. Using digital twins, smart factories could mimic the behaviors of manufacturing robots to test behavior and identify potential bottlenecks.

Digital Twin 2.0 Adds More Data

Using a digital twin, engineers could represent complex interworkings of joints and parts within a computer screen — a 3D reflection of the device. As opposed to constructing physical models, virtual simulations significantly reduced the effort and resources required to test new concepts and diagnose problems. But, simulating reality in a black box wasn’t always easy.

Reproducing complex physical counterparts with a digital twin is wrought with complications that can be difficult to model in a standard CAD simulation, said Gomez. So, engineers began taking measurements from physical devices, such as vibrations or temperature, and integrating actual production data into the twin. This enabled operators to better forecast system performance by considering real-world elements. Yet, truly predictive forecasting was still lacking. That’s where AI comes in.

Digital Twin 3.0 Adds AI

Up until recently, digital twin and AI have been independent concepts. But with the advent of more sensors and greater data collection, integrating AI is becoming an inevitable evolution of the digital twin, said Gomez.

Adding an AI layer to a digital twin would involve training a deep learning model using hundreds of time-series data outputs from sensors. Generating this data would require capturing a chronological view of how systems work functionally for some time. “Then, take data and split it,” said Gomez. “Use some to train, some to test.” The process is not too dissimilar to Walk Forward Testing, common in financial trading, added Gomez.

Instead of using traditional statistics methods and standard physics, a neural net could unify data and find nonlinear relationships between data regardless of type. The end result could quickly identify cause-and-effect correlations between data sets (which simulated physics engines may miss) and predict future conditions based on new input.

Use Cases

With better intelligence, you get a more accurate depiction of possible outcomes. The use cases for crystal ball digital twins are numerous. Gomez described how 3D printing and factory maintenance could utilize digital twins:
- Additive 3d printing: 3D printing metal powder involves a complex thermodynamic process with high-intensity lasers. The process is often less than perfect, leaving cold and hot spots from layer to layer, but ignoring them could result in a defect. By analyzing each layer’s thermal displacements, a deep learning model could be trained on the intricate details of the process. This could be used to build a more refined process model, essentially enabling manufacturers to “pre-compute the part.”
- Predicting glass quality: Gomez described how a specialty glass company utilizes AI-driven digital twins. Their process model takes sensor readings at various chambers throughout its molten melt and cooling process, analyzing temperatures to maintain a uniform mix. Based on their controls, operators can predict what glass quality will be in the future. Essentially, it’s “a user assistance system based on a digital twin,” described Gomez.
As you can see in the examples above, a digital twin isn’t necessarily a single object — it could represent an entire process model for a large industrial operation. According to Gomez, having this digital twin could boost testing and R&D, improve development time, and decrease time to market.

Digital Twin 3.0 Forecasts the Future

For digital twins to become more effective, these simulations must be faithful to current and future real-world conditions. But, computing tests for situations involving wet chemicals, unstable materials, or thermodynamics is tricky. Therefore, to Gomez, predicting such dynamics really requires “learning directly from the process model,” he said.

The key thing here is a neural net doesn’t care what it’s monitoring. Be it torque, matter, friction, temperature, fumes or vibration, the model will learn regardless of what’s thrown at it. While the benefit here is you don’t have to know physics or chemistry, setting up this process requires much customization, which could differ significantly on the type of materials and process at hand.

The fusion of disparate data sets could bring interesting capabilities for testing and forecasting. Yet, quality and quantity of data is paramount, noted Gomez. Furthermore, these models won’t spring up in an instant — they must be tested and validated using real-world dimensions before deemed useful. While digital twin 3.0 is a promising step forward, more research will be required to ensure the predicted digital future reflects the physical outcomes.

AI-infused digital twins use “data from the process to predict what the process will be in the future,” said Gomez. This goes far beyond traditional 3D representations to produce more faithful, predictive digital twins.
March 15, 2021
How the Pandemic Renewed Respect for the Agile Mindset

Agile methodologies were introduced to us around 10 years ago. In that time, we have seen technology advance at breakneck speed and faced many new challenges in the way we work; arguably, never more so than in 2020.

However, despite the abundance of change we have experienced, the core values of Agile have stood the test of time. Yes, Agile has been agile, adapting to fit our individual needs. But its values and principles are so strong that they ring true for each and every organization touched by this way of working.

It’s impossible not to mention 2020, and how Agile shifted and adapted to help us through this turbulent time. What did we notice? Well, much like the renewed gratification you feel for your automotive breakdown service when your car gives up the ghost for the first time in years, we noticed that the COVID-19 pandemic changed Agile in a different way: by providing renewed respect for the agile mindset.

What is the Agile Mindset?

When we talk about the agile mindset, we’re referring to the core values that combine to establish a set of attitudes held by those embracing agility. There are four of these core values: Make people awesome, deliver value continuously, make safety a prerequisite and experiment and learn rapidly.

All four values are of equal importance, but they each have a unique impact on the mindset. For example, making safety a prerequisite means providing employees with the confidence to experiment, innovate and not fear mistakes or failure – these are all natural on our path to achieving new things.

Additionally, delivering value frequently benefits both our customers and employees. It takes away the pressure of bouncing from one milestone to the next and adds value to a consistent level of delivery. Our customers are happy and grateful, seeing constant developments and improvements to what we provide them.

The final two values (make people awesome and experiment and learn rapidly) are those that were particularly important during the change and adversity of 2020. Let’s dive into them.

Making People Awesome!

Agile methodology is massively focused on people: both employees and customers. When we work in an agile way, we want to enrich our people and give them the freedom to express themselves and show off their skills. This, in turn, helps the entire organization to deliver excellent service to our customers.

With such a focus on people, the mandate for remote work brought about by the COVID-19 pandemic introduced an obstacle to agile ways of working. Our only human interaction with colleagues and customers was through a screen, which, let’s be honest, just isn’t the same as interacting in person.

Therefore, employee engagement has become more important than ever. Virtual interactions make it harder to truly see how somebody is feeling about work – whether they are happy or unhappy, motivated or unmotivated. It’s important to check in with everybody regularly; ask them directly how they’re doing and encourage honest answers. Keep the Agile team spirit alive by making an effort to break the screen barrier during meetings.

There are benefits of remote working for Agile, too. For example, it offers a fantastic work-life balance. When employees are less pressured by commuting or less exhausted by the constant energy of the office, they are happier. And happy employees make happy customers!

So, the value of Agile’s ‘Make people awesome’ tenet became even more important and respected in 2020. We realized that we must optimize our employees so that they can bring their best selves to work, even during uncertain times.

Experiment and Learn Rapidly

This been an incredibly important value, hasn’t it? For lots of us, remote working was a brand-new experience. Perhaps we’d spend the odd day working from the sofa to let the boiler engineer in, but five days a week from home – unprecedented!

Learning and innovating at speed has been key to being able to work effectively from home. We’ve been truly embracing this aspect of the Agile mindset. But how? Essential to agility is the ability to critically review how we operate. Almost half of businesses say they do this every quarter (43%) and 21% say they do this every six months.

Regularly reviewing and analyzing how we work helps us to identify areas of improvement, areas that we could experiment with innovation, and gaps in our knowledge. Without this, we’d be walking through our working life with a blindfold on, and likely not be able to pivot in the face of change and adversity.

A great example of the renewed respect given to the ‘experiment and learn rapidly’ value is the COVID-19 vaccine. It normally takes years to develop, test and roll out a vaccine, but we’ve seen this happen in just months.

You wouldn’t be mocked for not knowing that the vaccine was being developed way before the pandemic of 2020. In fact, scientists began preparing for ‘Disease X’ over four years ago. They analyzed the response to the Ebola outbreak of 2014 and recognized a need to develop a vaccine that could be used quickly, for an infection that did not yet exist.

Fast-forward to COVID-19, and while scientists still had lots of work to do to prepare a specific vaccine (designing; initiating the correct immune response; testing and more testing and roll out), their agility, started years ago, meant they had a strong foundation on which to build.

This value has definitely received more recognition in recent months. This is great, because it’s going to be vital for the continued response to our changing world. We must continue to analyze our response to new ways of working and adapt based on what we find. Are you already experimenting and learning to be ready for the new normal?

An Essential Mindset for Remote Teams

The core values of agility have had a huge part to play in our adaptation to the changes we saw in 2020. And many of us have embodied this agile mindset without even realizing – we’re calling this ‘unconscious agility.’

If you’ve tried something new in the face of remote working, made a conscious effort to deliver value continuously rather than in big chunks, checked in more regularly with your colleagues or relayed the message that mistakes and failure are a natural part of innovation, you’ve been working in an agile way. Even if your organization doesn’t consciously work agile, you can still embody this mindset.

And it’s going to be key for the new normal – we should already be looking ahead to that. We didn’t have time to prepare for what came in 2020 – it was somewhat of a surprise. But we do have time to prepare for what comes next, and the Agile mindset is key for tackling this successfully.

March 9, 2021
The Promise of AI for DevOps in 2021
DevOps is a natural target for AI-driven efficiencies, as it involves frequently repeated processes that generate mountains of data. It seems reasonable to expect that, like other domains that require decisions to be made based on large volumes of data, AI will play an important role in DevOps, too.

Definitions of AI vary considerably, so you can’t be blamed if you’ve sat through a discussion of AI and DevOps and still don’t understand exactly how the two intersect. But the bottom line is that AI will prove most useful in situations where there’s lots of data generated by, or passing through, a repeatable process. Humans are pretty good at identifying heuristics to help them make reasonable decisions based on patterns in data. But machine learning (ML) techniques bring with them the promise of teasing out inherent characteristics that underpin the data, and that are often impossible for humans to observe.

There are two main points in the DevOps process where large amounts of data are generated, and where machine learning would be most useful when applied: testing and release and monitoring.
1. Testing and Releasing
  
  Deployment packages: AI can analyze trends in what is actually being deployed. My company, Gearset, is a DevOps solution for development on the Salesforce platform. In that context, AI could track the items of Salesforce metadata a team usually deploys, and optimize requests for retrieving that metadata from its org based on those items, speeding up comparisons and deployments, and, ultimately, release cadence.
  Deployment errors: At Gearset, increasing deployment success rates is a constant focus. To that end, we aggregate and analyze data from deployment errors to identify the most common deployment-blocking errors. We then build problem analyzers that suggest automatic fixes to users. With machine learning running on telemetry data, we could more rapidly identify other patterns of use that trigger common deployment errors, and suggest new problem analyzers we should build, boosting deployment success rates still higher.
  Static code analysis: Static code analysis generates data about the quality and security of new code, judged against a ruleset. Within Gearset, Salesforce developers can choose and customize the PMD rules they want in their ruleset, so they’re warned about the code quality issues they care about. But richer insights would be possible with AI, such as high-priority areas for improvement and refactoring based on trends in code quality and security.
2. Monitoring
  
  Infrastructure monitoring. Huge amounts of data can be generated from DevOps monitoring. It’s easier to know what to focus on with AI-driven insights into performance log monitoring. Pattern recognition can also predict usage growth and help with capacity planning.
  Security. This has been a key area for innovation in recent years, with the development of products that use machine learning to enhance threat detection, intrusion detection and vulnerability database compilation.
  Unit testing. Gearset provides tools for monitoring code in Salesforce, such as automated unit testing, which reveals when code is no longer executing as intended. AI could identify patterns in the logs and suggest areas of the codebase that appear to require attention.
  Change monitoring. Changes in the codebase, whether expected or unexpected, are tracked by change monitoring and backup jobs. Gearset currently has smart alerts on backup jobs that users can manually set up to be warned of changes or deletions that are unusual, both in terms of the kinds of records being deleted and how many. But AI could automatically spot anomalous and unusual patterns of churn that should be investigated.
In summary, AI promises to accelerate innovation in the areas where we currently use data-driven insights to improve the performance of DevOps tools and processes. The result will be even higher deployment success rates leading to increased agility, better code quality and performance, and enhanced security.
March 5, 2021
GrammaTech Allies with GitLab to Advance DevSecOps

GrammaTech announced today it has partnered with GitLab to integrate its GrammaTech CodeSonar static application security testing (SAST) tools with the GitLab Ultimate DevSecOps platform.

Vince Arneja, chief product officer at GrammaTech, said integration with continuous integration/continuous delivery (CI/CD) platforms such as GitLab is critical because it enables security scans to run automatically any time code is merged. That capability reduces the amount of code that is scanned at any one time, Arneja said.

GrammaTech is partnering with multiple CI/CD platforms and integrated development environment (IDE) providers to make it simpler to create multiple points for scanning code during the application development process, Arneja noted.

GitLab, meanwhile, is providing its own tools for analyzing artifacts as they move through the software development life cycle. The GrammaTech tools, available via the highest tier level made available by GitLab, analyze code at a deeper level, said Arneja.

Ultimately, the goal is to enable developers to discover security flaws as early as possible in the application development life cycle. The later those flaws are discovered, the more expensive they become to fix, Arneja said.

Developers, naturally, tend to postpone security scans as they race to meet an application deadline. That practice creates issues; the more code there is to analyze, the longer such scans take. It’s generally more efficient to scan smaller amounts of code more frequently. Otherwise, developers can become overwhelmed by the number of security bug fixes that need to be addressed at the back end of the application development process. Automating security scans allows an organization to move toward embracing DevSecOps best practices in a way that doesn’t rely on a developer remembering to initiate a scan.

Most developers are not deliberately ignoring security issues – it’s just that the existing, manual processes for discovering those flaws is inefficient.

Automated scans also provide the added benefit of simplifying discovery of common security flaws long before a code review, creating more time to address significantly more complex issues.

Application development teams are also under pressure to reduce the total number of bugs that need to be fixed after an application is deployed. As the number of applications being deployed steadily increases, developers can find themselves spending more time fixing bugs than writing new application code.

Most organizations are not very far along in their journey toward embracing DevSecOps. However, as it becomes easier to integrate a variety of scanning tools within DevOps workflows, the number of organizations moving up the DevSecOps maturity curve should increase. In the wake of some recent, high-profile attacks on software supply chains, the sense of urgency surrounding the adoption of DevSecOps best processes has undoubtedly increased.

In the longer term, there may soon come a day when security is viewed as just one of many quality assurance gates that code needs to pass through before it’s allowed to be promoted. In the meantime, an ounce of cybersecurity prevention at the front end of any application development is most certainly going to be worth more than several pounds of cybersecurity cure applied too late.

March 4, 2021