devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

Tackling CostOps When You’re a Developer

The implementation and successful execution of IT initiatives often comes down to developers. From those working with commercial vendors to those working with open source projects, cloud-based software-as-a-service (SaaS) solutions, managed service providers (MSPs) and internal teams, they all play an important role in the successful running of IT and operations teams.

One challenge developer and operations teams face is the huge time barrier between development and follow-on operations. What a developer builds today for an organization may continue to be used decades from now, and will likely be maintained, patched, updated and modified by other developers. Though it’s a point of pride for the developer—who will have likely moved on in their career—it can be challenging for the operations team who has to continue to deploy it year after year.

With more applications than ever before, the traditional role of the developer is changing. Today, developers need to start factoring operations cost containment into their responsibilities.

Opportunity for the Developer

Developers are rarely responsible for long-term business decisions. Once code is out of their hands, they often have little to no stewardship of their work. The business will make critical IT cost optimization and containment decisions about its code, language and toolchain epochs later. Developers focus on the now and the near future. Spending hours envisioning the one winning outcome out of 10,000 possibilities years later won’t get code out the door or achieve the delivery goals of their managers.

However, developers have an often-overlooked opportunity to include the gears to activate cost containment support during initial development. From there, if their work is good, it’ll endure; extended support will eventually be necessary. The first step is to ensure new and modernized applications include solid cloud-native monitoring from the outset. This not only helps DevOps and SRE teams but benefits the entire business, who’ll own those applications for the long term.

Integrating operations-focused monitoring is a top priority for developers. In some cases, an application using platform-managed serverless or orchestrated containerization has no shortage of opportunities to provide developers and operations with detailed performance data.

A developer’s expertise with dependency analysis, code maturity and ease of integration is a great measurement tool to evaluate tool durability. A solution capable of easily combining cloud-native application performance details with infrastructure performance, user experience and operational expense data is even more likely to help developers and businesses manage costs in the long run.

A New Dimension

As cloud-native becomes a mainstream enterprise strategy, cost containment is a key opportunity. To meet the future challenges of application management, leadership is rapidly expanding their definition of application suitability and quality to incorporate all aspects of application ownership. For some teams, cost containment is a new dimension of senior developer maturity.

March 14, 2022
CircleCI Acquires Ponicode to Gain AI Testing Tool

CircleCI today revealed it has acquired Ponicode to gain control over a unit testing platform infused with artificial intelligence (AI) that makes it simpler to review application code prior to uploading it into a build. Financial terms of the deal were not disclosed.

Jean-Philippe (JP) Leblanc, senior vice president of engineering at CircleCI, said the goal is to integrate Ponicode’s testing technology within CircleCI’s continuous integration/continuous delivery (CI/CD) platform. That approach will make it possible to apply algorithms to individual developers’ code as well as to code aggregated from multiple developers within a build as it is continuously updated across a DevOps workflow, he added.

Ponicode was initially launched in June 2020 as a JavaScript unit testing extension for Microsoft VS Code. Since then, the company has started to support TypeScript, Java and Python, including complex functions such as variable mocking and infer suggestions of complex structures for nested objects.

The issue that DevOps teams frequently encounter is that even when individual developers test their code prior to uploading into a build, integrating different developers’ code can still result in an application failure. The Ponicode AI testing tools will give both developers and IT operations teams more confidence in the quality of the code being employed to drive applications, noted Leblanc.

Although not many developers want to admit it, Leblanc noted there is still a lot of sloppy code finding its way into applications.

In addition, Leblanc said the Ponicode acquisition will help the code review process become more efficient. Instead of requiring another developer or dedicated tester to review code, he said most issues will be surfaced by the AI testing tool that provides the equivalent of a built-in peer review. As a result, AI testing tools will improve the overall quality of the code being used to drive applications, added Leblanc. Developers will also be able to spend more time on the business logic that drives their application than on code reviews.

The goal, however, is not to eliminate the need for dedicated testing teams as much as it is to augment them and the developers they work with, said Leblanc.

It’s not clear to what degree responsibility for testing code is shifting left toward developers. However, many developers would prefer to have issues surfaced via an AI tool so they could address issues on their own rather than having them discovered by someone else. In fact, there are already more than 20,000 users of the Ponicode AI tool that plugs directly into developers’ integrated development environment (IDE), said Leblanc.

In general, there’s never been a greater focus on developer productivity. Organizations are attempting to simultaneously build and deploy more applications than ever—thanks mainly to digital business transformation initiatives launched in the wake of the COVID-19 pandemic. The challenge they face is recruiting and retaining developers. As a result, organizations are looking for ways to increase developer efficiency by eliminating as many manual processes as possible.

March 9, 2022
Secure Software Summit Series: Focus on Preventative Readiness
The connected world economy and the COVID-19 pandemic forced companies to accelerate digital transformation. Sophisticated cybercriminals have seized this forced acceleration to lay the groundwork for cyberwarfare. In reaction to recent attacks ranging from the SolarWinds breach to the recent Log4Shell exploits, many companies have quickly isolated and patched their systems. However, these reactive fixes do not work all the time; nor does the watch-and-wait approach. We must focus on re-engineering our organizational operations and culture to build and maintain preventative readiness. Companies and infrastructures need to be more resilient and secure from the start by building secure coding practices into the development process.

Secure Software Summit

At the beginning of 2022, ShiftLeft hosted the Secure Software Summit to provide industry experts and practitioners in the software development world a platform to discuss the latest methods and breakthroughs in secure coding and development practices—securing code earlier and better has become a discipline unto itself!

Some of the main takeaways from the event were:

SBOMs are in Your Future

In the very near future, organizations will need to better account for all the software and components of their applications, most likely via a software bill of materials (SBOM). The U.S. government has mandated barebones SBOMs, and we will soon see private industry start to mandate them, too, as part of procurement processes and auditing. This will enforce greater transparency and automate discovery of all dependencies and components in a way that, until now, was not common. Software composition analysis (SCA) will make this process easier and will become a standard part of the build process and the application development life cycle.

Securing Open Source is Critical

With Log4Shell and other open source software (OSS) supply chain attacks, application security teams must learn how to more intelligently update and secure the most critical OSS components and infrastructure. The average AppSec team needs to sift through massive piles of vulnerabilities and suggested security fixes — far more than they can possibly fix. We have seen record numbers of new vulnerability disclosures in each of the past four years. Proper prioritization based on whether a vulnerability can significantly impact an organization’s own applications and infrastructure is now essential amidst the blizzard of OSS dependencies that make up the modern application.

Digital Threats Impact the Real World

For many organizations in non-tech verticals such as health care that consume a lot of software, application security is at a crisis point—software vulnerabilities can literally put lives and our economy at risk. Researchers have correlated increases in mortality with hospitals running at higher levels of stress and capacity. When ransomware or other attacks impact health care institutions, the effect is the same as a massive pandemic flooding the ER: Doctors can’t use systems or equipment, care is rationed, patients are turned away and everything becomes more time-consuming. The net result is more deaths. Securing these systems against attacks becomes a matter of life or death—literally.

Culture Change Must Come First

Organizations will deploy new security architectures such as zero-trust, but these attempts will only be successful if AppSec and development teams change the culture around security. Organizations must recognize that the new normal is a state of constant renewal of trust. This will be challenging; constant renewal of trust requires entirely new infrastructure and a new mindset that can be hard on humans. It means implementing multifactor authentication in many more places and removing conveniences like administrative accounts that have blanket access to systems; it requires implementing least privilege practices. Software development will need to bake this constant renewal of trust into workflows and tooling to make it the new normal.

Shift From Reactive to Proactive

AppSec and development teams must shift from reactive approaches that tend to mobilize most resources during a breach or an incident and emphasize more proactive approaches such as better software security analysis and security chaos engineering. Knowing the unknown unknowns before they become a problem is key here. Netflix, which pioneered chaos engineering, recognized that stressing systems frequently and constantly to see how they behave under adverse conditions often yielded surprising insights that could improve security (and resilience, more broadly). As mentioned above, creating better ways to prioritize vulnerabilities and focus on the ones that are actually attackable shifts the task from a hopeless burndown to a targeted and proactive tactical exercise that is manageable.

Stay tuned for more articles to follow written by the following keynote speakers from the event:

Aaron Rinehart, Verica – Security Chaos Engineering

Dan Lorenc, Chainguard – The State of OSS Supply Chain Security

Steve Springett, OWASP – Behold the SBOM

Shinesa Cambric, Microsoft – Importance of Securing Software with a Zero Trust Mindset

Malcolm Harkins (Epiphany Systems), Rob Lundy (ShiftLeft) and Bryan Smith (RiskLens) – Reachability and Attackability

Abhishek Arya, Google – Measuring and Mitigating Risks in Open Source Software
March 4, 2022
4 Reasons Software Developers Need a Bill of Materials
The recent Log4j/Log4Shell vulnerability was a wake-up call that threats aren’t going to wait until the industry gets up to speed on software supply chain security. While the Log4j open source component vulnerability caught us all off guard, it did highlight the need for software vendors to be more proactive in disclosing the composition of their products. It’s become painfully clear that analyzing open source libraries and third-party code should become standard practice to understand their makeup and the potential risks they introduce in commercial software applications.

Unfortunately, relying on open source projects to provide visibility into security vulnerabilities isn’t going to work. In most cases, these projects are grossly underfunded. At the time of the Heartbleed vulnerability, for example, OpenSSL received very little funding. Yet, open source usage increases each year. It’s imperative that commercial software organizations contribute to open source projects they use and share responsibility for the security of these products.

In addition to open source libraries, most vendors source third-party code from contractors or for-hire development organizations. Without documentation of the composition of the code developed by third parties, it’s impossible for commercial software vendors to proactively identify and manage risk before it’s implemented in their development cycle.

Using Software Composition Analysis (SCA) Tools

Where a software bill of materials (SBOM) is not provided, the onus should be on commercial software vendors to create one. This can be accomplished using software composition analysis (SCA) tools that analyze binaries and do not require access to source code. They can generate SBOMs to identify open source or third-party components in use, as well as track and manage security risks in the software supply chain.

Creating a comprehensive SBOM provides other benefits, since most open-source projects and contract developers are only likely to publish direct dependencies (if at all) and not look further into the dependencies of dependencies, and so on.

Four Benefits to Consider

Meanwhile, commercial software vendors can expect their customers to soon start demanding SBOMs since this will be a requirement under the cybersecurity executive order. Given this evolving landscape, commercial software vendors should consider the following four benefits for proactively implementing an SBOM program to govern the products they build:
- Gain visibility into software supply chain risk to identify, reduce and remove vulnerabilities in reused software (i.e. open source and third-party). SBOMs provide data for business decisions on the software you have reused and purchased. It’s better to discover these risks before your customers do.
- Preemptive supply chain qualification to ensure compliance with future requirements. SBOMs will soon be a requirement for doing business with the U.S. federal government. Suppliers that meet the SBOM requirements during procurement will be given preferential treatment.
- Improved security and downstream benefits that come with risk management and mitigation. Avoiding, detecting and remediating security risks before they become embedded in a product pays huge dividends during development and deployment. You’ll be better prepared for the next security event.
- Common understanding of software assets that comes with a standardized SBOM shared amongst developers, suppliers and open source projects. An SBOM becomes a way to communicate software contents and dependencies within and outside an organization.
Taking a proactive approach to the software supply chain by creating SBOMs and demanding the same from suppliers will enable commercial developers to be better prepared for the next Log4j/Log4Shell vulnerability. It will also allow them to improve the software supply chain security posture of their end customers.
March 3, 2022
Tabnine, GitLab Build Custom Apps Faster With AI

Tabnine today revealed it has integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. Tabnine’s platform employs artificial intelligence (AI) to accelerate application development.

Brandon Jung, vice president of ecosystems and business development at Tabnine, said the goal is to make it easier for developers to automatically write code based on custom models created using AI. Those models would reside in the CI/CD platform provided by GitLab. Developers can now create custom models of their private source code, he noted.

The Tabnine AI assistant can then be trained on a customer’s private code, style and security best practices that have been defined by an internal DevOps team, added Jung. That assistant, accessible from within a developer’s integrated development environment (IDE), is conversant in 35 programming languages.

The code completion tool doesn’t eliminate the need for developers to write code; instead, it completes code once developers start writing it based on the model stored in the CI/CD platform.

Nima Badiey, vice president of global alliances for GitLab, said the overall goal is to increase developer productivity at a time when organizations are launching more application development initiatives than ever. Many of those applications are being constructed using multiple programming languages that each individual developer may not have equally mastered.

In addition, an AI model will, over time, improve the quality of the code being created, noted Badiey. That should make it easier to review code that is more accurate because it was created with the aid of a machine, he added.

In general, GitLab has been moving to incorporate AI within DevOps workflows. The company last year acquired UnReview, a provider of a tool that uses machine learning algorithms to identify which code reviewers to assign to a project based on both the quality of their previous efforts and their current workloads.

It’s not clear to what degree AI will be pervasively embedded within DevOps workflows. However, it’s now just a matter of time before algorithms are more widely employed. Organizations that employ DevOps today devote significant resources to maintaining platforms that could be simpler to manage if more tasks and processes were automated. In theory, more resources could be then devoted to building applications versus maintaining DevOps platforms.

One way or another, more organizations are moving to increase developer productivity. Developers are both hard to find and retain, so organizations have a vested interest in finding ways to increase the rate at which an existing pool of developers can build applications capable of driving a wider range of digital business transformation initiatives. Of course, an increase in the rate at which applications are developed also has significant implications for the rate at which they might need to be deployed.

Not everyone in IT is, of course, entirely comfortable with AI. Nevertheless, most DevOps organizations are highly committed to automating as many processes as possible. The only thing that will be different going forward is determining to what degree those processes will be automated by humans versus a machine.

March 2, 2022
Best Practices for Modernizing App Modernization

Modernizing legacy systems to embrace a loosely-coupled microservices architecture is the biggest predictor of success for continuous delivery, according to Google Cloud’s 2021 Accelerate State of DevOps report. Studies continue to show that the most elite DevOps performers enjoy more frequent code deployments, faster lead times to deploy, low change failure rates and faster time-to-recovery.

Leading enterprises like Netflix, Tesla and Starbucks proved that a microservices architecture minimizes fine-grained dependencies between services, which can then be independently tested, deployed and scaled. Combined with DevOps best practices, this reduces technical debt and allows for modernization based on a factory model approach that incorporates automated analysis and deep observability.

That said, application modernization to date has been a manual process requiring multi-year projects that suffer a high failure rate. How can we apply modern tools, known DevOps best practices and desired business benefits to improve and accelerate a company’s modernization efforts? In other words, how do we make modernization more modern?

By using automation, AI and data science, building repeatable pipelines and shifting architecture left, architects can get in front of technical debt before it becomes unmanageable. In this article, we’ll explore these practices in more detail.

Intelligently Automate Everything Possible

DevOps methodologies have taken manual steps and applied automation to create repeatable processes that scale. Modernization teams today are in dire need of these methodologies, as they are stuck with manual approaches that don’t scale across an entire application estate. Thus, applying intelligent automation, AI and data science to modernization—and creating a repeatable pipeline for refactoring—is a natural extension of DevOps successes over the last decade.

Continuous Integration, Continuous Deployment, and Continuous Modernization

CI/CD methodologies are a core best practice for DevOps teams and are already familiar patterns that development organizations are using for their application life cycles. But, there is no continuous delivery without continuous modernization. Elite teams continuously monitor technical debt accumulation and address it at every application release cycle, thereby implementing continuous modernization in their application life cycles.

Deep Application Observability

Observability, defined as monitoring, logging and tracing, is a foundation for cloud-native architectures. Modernizing an existing monolith requires deep observability beyond simple static code analysis to include deeper domain-driven behavior analysis and dynamically tracking dependency interactions. This is also the secret to uncovering dead code that is no longer used.

Ensure Architectural Parity

You must understand your infrastructure architecture to inform your application architecture and your modernization options. Lift-and-shift causes headaches for many organizations because the traditional three-tier architectures of monolithic applications have a completely different topology than cloud-native applications, which are designed from scratch to leverage the efficiencies of the cloud.

Whether it’s a hybrid approach (part on-premises, part cloud), public or private cloud, it’s important to ensure that your modernization strategy ensures architectural parity between the target application and its ultimate destination in the cloud. Also, it’s important to understand your modernization options: Rehost, replatform, refactor, rewrite, etc. What can you lift-and-shift and what needs more attention?

To find the answer, incorporating data science-driven analysis, automated service extraction and, more importantly, people, to help you understand the possibilities is critical.

Get Executive Support for Your Modernization Project

This isn’t about simply churning through your backlog; your executive sponsors for a project of this scope need to understand, in business terms, why this is crucial for the organization. There are plenty of metrics showing the financial and opportunity costs of maintaining mission-critical applications that are aging and problematic.

To get executive buy-in for your modernization initiatives, you need to formulate a business case that communicates the cost of maintaining the legacy apps, both in time and resources to maintain, but also the negative impact on innovation, customer acquisition and retention and speed to market.

DevOps practices emerged to improve how IT organizations reliably and efficiently deliver software from development to operations and out to customers. Applying these emerging technologies of automation, pipelines and deep observability to application modernization initiatives will enable teams to accelerate how they deliver application transformation projects. By investing in training application teams in these methods and providing modern tooling to support that training, organizations more reliably and more efficiently move both people and projects forward into the next generation of cloud applications.

March 2, 2022
Boosting DevOps Productivity Requires Visibility, Automation

Engineering teams continue to struggle with roadblocks and bottlenecks during the development process, according to Software’s recent 2021 Code Time Report.

The study, which is based on feedback from more than 250,000 developers using the Code Time plugin, found the median code time per developer is 52 minutes per day, or four hours and 21 minutes of code time per week.

The data also revealed that only about 10% of developers spend more than two hours per day coding, including on weekends, while about 40% of developers spend more than one hour per day coding.

The study also indicated developers are battling distractions that range from too many meetings and too many interruptions to too much wait time on processes and systems.

Distractions, Disruptions and Meetings Dog DevOps

The conclusion was most companies ineffectively deploy their development and DevOps teams, bogging down engineers with distractions, disruptions and meetings as well as system inefficiencies, such as slow reviews, slow builds and bad tools.

Software’s CTO Mason McLead said based on the company’s estimates, developers spend an additional 41 minutes per day on other types of work in their editors, such as reading code, reviewing pull requests and browsing documentation.

“The key to ensuring the highest levels of productivity from DevOps teams is visibility,” he explained. “We’re all biased toward focusing on what’s readily apparent, but the biggest bottlenecks are often hard to find and difficult to measure.”

McLead said by improving visibility across the entire development life cycle in a way that measures system-level metrics and not individual performance, DevOps teams can focus on the biggest constraint and have a more meaningful impact on their team’s productivity.

He said one example of a productivity metric with hidden barriers is lead time.

“I’ve spoken with many managers who disproportionately focus on how long it takes to review pull requests as a key lever to minimize lead time,” he said. “However, there are many stages in releasing a new feature that might actually be the key constraint—for instance, how long it takes to test and validate changes in a staging environment, or how long it takes to release merged pull requests to production.”

While these stages of lead time are all measurable, McLead explained most DevOps teams don’t have a data pipeline or BI tool set up to measure them.

He added that once an organization can diagnose the key constraint, it’s a lot easier to come up with an effective solution to minimize that constraint.

For example: If pull requests are taking a long time to create, are tickets being properly scoped? Can you see a correlation between the size of the pull request and the time it takes to be approved and merged?

McLean pointed out that if pull requests are taking a long time to be reviewed, it is critical to ensure proper expectations are being set.

He added it’s important to determine if there is a system in place to remind reviewers and enough time set aside in the day to perform the review.

“Taking steps to further automate deployment processes are another potential fix if it currently takes a long time to deploy a change to production,” McLead said. “It really all comes down to being able to measure the top constraint so that you know where to spend your time.”

Remote Work and Visibility

Remote work is also expanding the role of traditional DevOps teams: The trend toward more flexible working styles will demand more investments in DevOps such as secure provisioning of remote infrastructure, better access management and improved developer onboarding to better enable productivity for development teams.

“Visibility into how your DevOps investments are making an impact will play a big role in the decision on whether to stay remote or return to the office,” McLead said.

He added one way to attract and retain a highly productive DevOps team is to show that your DevOps investments are paying off.

“I recently talked to an engineering manager whose team wasn’t getting features out fast enough,” he said. “It took a month on average to complete a ticket, which had a significant impact on their ability to move major roadmap items forward.”

He explained that by implementing measures to improve throughput (e.g. investing in CI/CD, reducing build times and improving test coverage), they were able to decrease lead time from one month to four days.

By setting up a data pipeline and BI tool and increasing visibility, the engineering manager was not only able to report on metrics to his executive team and board with confidence, but also boost morale on his team.

From McLead’s perspective, retaining talented and trained DevOps engineers is critical because many DevOps projects require a longer timeframe in which to implement and measure their success.

“Highly effective DevOps teams measure not only how their investments are improving efficiency in the short-term, but also how changes in throughput and productivity are trending over months and years,” he said. “If your team is experiencing high turnover, it’s even more difficult to consistently deliver results over these longer time frames.”

March 1, 2022
What to Expect When Transitioning to DevSecOps
How do you ensure your DevOps pipeline is secure? Does DevSecOps protect you against serious breaches or is it just a way to allay the concerns of stakeholders about security in DevOps?

A data breach can cost an average of $3.92 million USD, as per IBM’s study Cost of a Data Breach. In this report, health care was found to be the most expensive industry, with breach fines averaging $6.45 million USD.

While DevOps delivers on the promise to increase the rate of delivery, the traditional CI/CD framework does not emphasize security. For the sake of speed, misconfigurations and known vulnerabilities may be allowed to pass through the development pipeline to production.

Security and testing are generally a low-priority activity, which means these vulnerabilities are fixed retroactively. This takes more time, effort and money. With rampant, unverified integration of open source tools, you open up the software to attackersthat could compromise the security of your apps, systems and users’ data.

DevSecOps is an upgrade to DevOps, allowing you to deliver security and compliance testing continuously. These checks get integrated within the CI/CD pipeline to enable the delivery of more secure code faster.

From DevOps to DecSecOps: What to Expect

The automated nature of DevOps delivers several benefits that enable teams to realize the true power of DevOps as silos break and delivery rates skyrocket.

As DevOps practices span the entire delivery pipeline, it provides the necessary mechanism to deliver audit, compliance and security requirements along with speed and efficiency.

There are many benefits of upgrading from DevOps to a dedicated DevSecOps practice, and they are important to understand before you embark on that journey.

1. No Restrictive Access Control Policies for Developers

Access to infrastructure assets must be strictly controlled and monitored to enforce requisite security measures. This means approval gates, secure configuration parameters and other security measures.

With DevSecOps built into the pipeline, these access controls can be automatically applied. This enables on demand access to infrastructure resources for the team and reduces their dependence on factors outside the team.

For example, many organizations have started deploying internal DevOps teams that enable automated access to a shared pool of deployment processes, tools, repositories, workflows, etc.

This team is usually separate from the IT team but enforces security mechanisms with the same rigor. It ensures that access to all the infrastructure instances required by development, QA or production is automatically tracked, monitored and controlled as per the guidelines. Additionally, inconsistent processes or misconfigurations are also controlled.

Often called the shadow IT team, the idea of this team is not to circumvent the IT department but to create an additional team that matches the agility of the DevOps team.

2. Seamless Security and Compliance Testing

Traditionally, security and compliance testing happened all at once at the end of the release cycle close to the release date. This typically meant that a large spreadsheet of issues is sent to the development team to be fixed immediately, since maintaining a consistent release velocity is the key to DevOps success.

This requires the development team have at least one dedicated resource to work on those issues. When metrics are tracked, to no one’s surprise, this method resulted in negative impacts on the velocity of the next release cycle.

DevSecOps applies all the security and compliance checks in batches. So, testing for security and compliance is shifted left and spread out across the pipeline.

This makes the security feedback loops shorter and more frequent, thus aligning security and compliance testing with the DevOps philosophy. As more secure code is committed every time, the possibility of security and compliance errors reported by the QA team is minimized.

A second, more personalized approach is using the integrated development environment (IDE) itself to take security and compliance checks to the developers. With regular and automated security and compliance baked right into the development process, this process is sped up considerably and the development team becomes self-reliant.

3. Overcoming the Risks Associated With Open Source Software

The 2019 State of The Software Supply Chain report from Sonatype showed that, on average, 85% of the codebase among modern applications uses open source components. While open source components enable innovation, they also come with considerable security risks. As more of these open source tools are added to the software supply chain, it increases the risks on the cybersecurity front.

The same report showed evidence to back up the need for greater open source software security checks and processes. Companies that managed their open source components released 55% less vulnerable components than those who had no verifiable open source management process.

While many of these open source components released frequent patches, it is also important for the DevSecOps team to step in and regulate the open source components. Some of the ways DevSecOps teams can do this are:
- Create a formal component management plan which makes sure that when employees leave, the practice doesn’t go away with them. Having a documented plan lets you look at the bigger picture of your pipeline and find vulnerable components that may be skipped without a formalized process. Incremental improvements to this plan are also possible if it’s well-documented.
- Use scanning tools like Gemnasium and Snyk that help regularly check for vulnerabilities.
- If vulnerabilities are detected or reported in a component, look at either updating or replacing the component.
- Enable quick approval for new open source software. Alternatively, prepare developers to test new components using security and compliance checklists.
4. Overall Cost Reduction and Acceleration of the Delivery Rate

An integrated security and compliance framework in DevOps prevents breaches and guarantees faster recovery when breaches do happen. As developers don’t have to set aside a large chunk of time to work on security and compliance violations, this shortens release cycles and ensures more secure code at the same time.

The fewer breaches you identify and fix, the more money you save on overcoming security disasters.

5. Automated Compliance Reporting

DevSecOps automates your security and compliance tests and it also logs and documents all the tests. DevOps automation platforms collect large amounts of information for the build, test, integration and deployment phases. This data can be used to create an end-to-end audit trail without any manual intervention or extra time spent scouring through various tools to prepare compliance reports.

A fantastic advantage of DevSecOps is the complete traceability from day one and automated compliance reporting. DevSecOps also focuses on the automation of testing, allowing you to deliver a secure development framework on a continuous basis.

DevSecOps is the Future of DevOps

The rapid release velocity DevOps enables is not without its disadvantages. In particular, the unchecked use of open source tools in the pipeline can expose your applications and systems to many known vulnerabilities, increasing the probability of a breach. Combined with a general lack of focus on security, this is a recipe for an expensive security incident.

To counter this, DevSecOps radically transforms the pipeline by shifting security and compliance testing left. Developers check the code before every commit. With fast feedback loops, they fix any reported vulnerabilities along with other errors in the app.

With DevSecOps, compliance and security checks are not done all at once; instead, developers chip away at vulnerabilities and security flaws with every release.
February 28, 2022
Tricentis Expands Scope of Cloud-Based Testing Tools

Tricentis this week extended a suite of cloud-based testing tools that promise to make it simpler to both develop cloud-native and mobile applications and migrate existing applications to the cloud.

New capabilities added to the portfolio include integrations for cloud-based planning tools and a wider range of testing capabilities for mobile applications. DevOps teams can now, for example, deploy Tricentis qTest platform for managing the testing process within a Kubernetes cluster. Tricentis has also made it simpler to configure and update its Tosca suite of application testing tools.

In addition, Tricentis added additional capabilities for testing SAP applications running in the cloud that previously were deployed in an on-premises IT environment.

Martin Klaus, vice president of product marketing for Tricentis, said the goal is to make it simpler for DevOps teams to integrate continuous testing for various types of applications within their DevOps workflows. DevOps teams have the option of invoking the Tricentis suite of testing tools via a software-as-a-service (SaaS) platform or deploying them on a cloud platform themselves using templates provided by Tricentis.

While developers are clearly getting more involved in testing, Klaus said it’s critical for testing capabilities to be integrated within a DevOps pipeline. Each developer is typically only working on a component of a larger application. Unless testing is conducted on an end-to-end basis, an organization won’t be able to determine the real quality of the application experience before deploying software in a production environment, he noted.

As a result, the decision about what tools to use as part of a continuous testing process is now being made by DevOps team leaders rather than individual developers, added Klaus.

Ultimately, the goal is to automate as much of the continuous testing process as possible. Achieving that goal will require increased reliance on artificial intelligence (AI) technologies, though to varying degrees, said Klaus. Those capabilities, however, are not likely to eliminate the need for dedicated testing professionals; instead, AI will enable those teams to more efficiently test increasingly complex application environments, he added.

In fact, it’s becoming practically impossible for testers to manually inspect every element of an application without the help of, for example, algorithms that apply computer vision to analyze a user interface, noted Klaus. There will always be higher-level tasks that require a human, but AI technologies will play a significant role in enabling testing at scale as organizations start to build more applications, he added.

In the meantime, it’s clear that there’s a lot more riding on testing as organizations continue to launch digital business transformation initiatives. In many cases, organizations only get one chance to convince end users that a new application being rolled out is better than the processes they previously employed. As such, the need to streamline testing within the context of a DevOps workflow has become critical—there is little tolerance for bottlenecks that slow down the rate at which applications now need to be built and deployed.

February 25, 2022
How SREs Benefit From Feature Flags

When you think of who uses feature flags, your mind most likely goes to software developers. In general, feature flags are closely associated with software engineering.

But site reliability engineers (SREs), too, can benefit. SREs may not be the ones to create feature flags, but they should work closely with developers to ensure that the applications their teams support include feature flags.

Here’s why feature flags benefit SREs, and what SREs can do to make sure their organizations take full advantage of them.

What Is a Feature Flag?

A feature flag—also sometimes called a feature toggle—is a technique in software engineering that allows developers to turn specific features on or off at application runtime. In other words, they let you control which features are available within your application when it’s deployed to production.

Feature flags can be configured in such a way that they enable features to be toggled on or off for specific sets of users, rather than an entire set of end-users. This is useful if, for example, you want to turn on an experimental new feature for users who have agreed to test it without exposing that feature to your general user base.

Usually, developers and SREs use feature flags to turn features on and off manually. But you could automate the process by, for example, writing a script that automatically shuts off a feature if your observability tools determine that the feature is causing a problem for users.

Why Developers Love Them

The main reason why feature flags are popular among developers is that they make it easy to implement and experiment with new features while keeping the development pipeline simple.

Without them, developers would have to create a new application release every time they wanted to implement new features. If any of the features in that release turned out to cause a problem, they’d have to remove the features from the code or fix the buggy features, then deploy a new release. This approach is tedious and it leaves teams prone to delayed releases and application rollbacks.

But with feature flags, developers can continuously add new features to an application without worrying that bugs within those features will lead to a rollback or a delayed release. If one feature has a problem, developers can simply turn it off using a feature flag, without having to do a new release.

How SREs Can Benefit

It’s not just developers whose lives are made easier—SREs, too, can leverage feature flags as a way of supporting the core SRE goal: Maximizing reliability.

That’s because feature flags minimize the risk associated with fast-moving software development pipelines. They allow teams to experiment with new application functionality—which is important if they want to keep pushing out application enhancements to delight users—while at the same time providing a safeguard against buggy feature implementations.

Imagine, for example, that you’re an SRE and you discover that the latest release of an application you support has a severe latency problem due to an issue with a new networking feature in the app. If that feature is controlled via a feature flag, you can remediate the issue very quickly by simply switching it off. You don’t have to wait for developers to fix the underlying code issue before you can solve the problem for your users.

Limitations

This doesn’t mean, of course, that feature flags are a cure-all against reliability problems.

They won’t help you if the root cause of your reliability issue lies within your infrastructure rather than your software. If an app crashes because you misconfigured your Kubernetes clusters or you ran out of server capacity, for instance, you can’t simply turn the problem off with a feature flag.

Note, too, that feature flags can only be applied to specific features. In other words, they can only control application functionality if developers deliberately created one to control that functionality before releasing the app. If you discover a bug that’s not managed by a feature flag, the only way to remediate the issue is to redeploy the application (or microservice, if the problem is limited to just one microservice).

How SREs Can Encourage Feature Flag Use

As an SRE, you most likely don’t have direct control over the software development process. You’ll therefore need to collaborate with developers to ensure that they build feature flags into their applications.

Doing this is simple enough. Start by educating developers and making sure they understand the benefits. Be sure, too, to identify which features are most likely to create reliability issues, so that developers can prioritize creating feature flags for them. And consider factoring them into your incident response playbooks, which will ensure that incident response teams remember to take advantage of them when possible to remediate issues quickly.

February 25, 2022