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.

How to Get Platform Engineering Just Right

If you want your organization to start moving toward a more efficient and streamlined digital transformation, platform engineering is the only way to go. However, without a defined roadmap, most organizations will pretty quickly feel like they’ve wandered into the tech wilderness without a GPS. According to the State of DevOps Report 2023, it takes, on average, three years for platform engineering to start showing tangible results—but, in reality, the majority of companies will be struggling for a lot longer.

Getting platform engineering right will help organizations create an environment that energizes their teams to develop solutions more efficiently and with greater reliability, ultimately driving business growth. Below, I have set out some of the critical steps that organizations need to take to ensure that the right guardrails are put in place to achieve all of the benefits of platform engineering whilst avoiding some of the common pitfalls.

Step 1: Define Governance – Creating Order Amidst the Chaos

Before embarking on your platform engineering journey, it is crucial to define an effective governance framework. So many organizations attempt to implement new strategies without having a clear understanding of the whos, hows and whats of their processes, which has the net result of creating further complexity.

Start the process by determining your team’s roles and permissions and establish a center of excellence. In doing so, every team member will know their responsibilities and areas of expertise with a clear and comprehensive access control and permission structure. Follow this by creating clear governance policies and procedures which will serve as guidelines for how the platform will be managed and maintained to ensure consistency and security throughout the platform’s life cycle.

Step 2: Set up Your Service Catalog – Building a Digital Buffet

By seeking to improve the developer experience first, organizations will achieve better platform engineering results, which is why one of the most important parts is defining what goes on the digital menu. Once you have established an effective approach to governance, choose which services you want to integrate into your service catalog and self-service portal in a full GitOps approach, which is maintained by the platform team.

An effective platform lets anyone interact with tools and the cloud without needing to be a technical expert. It’s like having a tech buffet where anyone can choose their meal, but only if the self-service portal is intuitive and has a user-centric interface. Access controls need to be built into the platform with predefined governance so that users can only request services for which they have the right permissions.

Step 3: Improve Observability – Shedding Light on the Cloud

In the land of digital transformation, seeing is believing, which is where observability has a role to play. Improving observability is crucial for gaining insights into the platform’s performance and behavior, which involves integrating tools like event and project monitoring, cloud cost transparency, application performance, infrastructure health and user interactions.

In a rapidly growing cloud environment, observability enables teams to keep track of what is happening in terms of cost, usage, availability, performance and security across a constantly transforming cloud infrastructure. Once a project has been deployed, it needs to be managed and maintained across all cloud providers, something which is critical for keeping costs to a minimum but is often a huge and messy task.

Managing this effectively requires monitoring key performance indicators (KPIs) and setting up alerts for critical events, and using logs and analysis tools to gain visibility into application behavior, track errors, and troubleshoot issues more effectively. Finally, implementing tracing systems that can track the flow of requests across various microservices and components helps to identify performance bottlenecks, understand latency issues and optimize system behavior.

Step 4: Plug CI/CD Pipelines – All Aboard the Automation Express

The next step is to turbocharge the platform by plugging in the CI/CD pipelines. These pipelines, connected to your Git, will generate templates with embedded automation, which allow automatic testing of code changes whenever developers commit or merge code into the repository. In doing so, this drastically reduces human error and ensures consistency throughout.

Following this with continuous monitoring and feedback mechanisms in the CI/CD pipelines ensures that only reliable, well-tested code makes it into production. These pipelines are orchestrated through APIs, which will make the digital journey faster and smoother.

Step 5: Set up FinOps & GreenOps – A Balancing Act for a Brighter Tomorrow

Finally, getting platform engineering right is as much about getting the technical basics right as it is about taking responsibility. By combining FinOps and GreenOps approaches and placing sustainability at the orchestration layer to empower users across the organization to consume less infrastructure, organizations can reduce software delivery/cloud costs and even their carbon emissions.

As I’ve written before in these pages, FinOps and GreenOps strategies go hand in hand – integrating cloud cost management and carbon footprint management is the most effective way to ensure that your journey is not just efficient but also environmentally conscious.

And that’s it. By defining governance, setting up an effective self-service portal, improving observability, plugging in CI/CD pipelines and embracing FinOps and GreenOps, organizations will be well on their way to creating a platform that’s not only efficient but also environmentally responsible.

February 2, 2024
OX Security Optimizes DevSecOps to Improve Application Security

OX Security this week updated its application security posture management (ASPM) platform to enable DevSecOps teams to instantly identify applications running in production environments that are running code that could be potentially exploited.

The ASPM platform from OX Security leverages large language models (LLMs) to identify vulnerabilities. The latest version adds an ability to confine the number of alerts generated to instances of code that can actually be exploited.

OX Security CEO Neatsun Ziv said that approach reduces the number of alerts that would otherwise be generated by 99% to enable DevSecOps teams to focus their limited resources on the 1% of alerts that represent an actual risk to the business. OX Security achieves that goal in part because its scanners are integrated with source control, continuous integration/continuous delivery (CI/CD) platforms, registries and cloud computing environments.

The overall goal is to reduce the amount of manual effort currently required to consistently maintain DevSecOps best practices.
The primary reason many vulnerabilities are never addressed is that DevSecOps teams are simply overwhelmed by alerts. Most of the alerts generated by a cybersecurity team are not immediately relevant because either the vulnerability is not present in the application running in a production environment or the application doesn’t connect to the internet.

The OX Security platform makes it possible to identify application security issues that need to be prioritized because it has been confirmed a vulnerability exists that can be exploited, said Ziv.

No matter how precise the alert process becomes, a DevSecOps team will still need to manage it, added Ziv. However, as the alerts generated become more relevant, it should become easier to bridge the historic divide between application developers and cybersecurity teams. Too many developers routinely ignore vulnerabilities identified by cybersecurity teams simply because previous efforts to identify the actual severity they represent have ultimately been a waste of their time.

The challenge just about any organization encounters when trying to better secure their software supply chains is, not surprisingly, getting application developers to buy into the DevSecOps process. Most developers are going to actively resist any approach to remediating vulnerabilities that takes time away from building new applications. Most of them only allocate about 10% of their time or less to remediating vulnerabilities. As such, it’s incumbent on a DevSecOps team to find ways to address application security issues in ways that don’t adversely impact developer productivity.

Organizations could mandate that vulnerabilities be remediated. In fact, there is a growing body of regulations that will require organizations to do just that unless they can prove the vulnerability in question cannot be exploited. The only way to effectively make that case will be to rely more on automation to document that the code running in a production environment is actually secure.

In the meantime, developers should expect to see their code scrutinized more than ever. Of course, the better part of valor is to ensure that as many vulnerabilities as possible are never introduced.

February 1, 2024
Cycode Discloses GitHub Actions Vulnerability in Google Bazel Project

Cycode today revealed it discovered a command injection vulnerability in the way the GitHub Actions continuous integration/continuous delivery (CI/CD) platform was used to update the open source Bazel project that many organizations employ to build and test software.

The vulnerability, now remediated, could have been used to create a backdoor through which malicious code could have been inserted into a codebase that is managed by Google.

Cycode researchers shared their discovery with Google, which has since updated the way it employs GitHub Actions to manage the Bazel codebase. Specifically, Google updated the base permissions to embrace least privilege principles to resolve the vulnerability discovered by Cycode.

The vulnerability was discovered using RAVEN, an open source tool for scanning CI/CD platforms for vulnerabilities that Cycode makes available.

Elad Pticha, senior security researcher for Cycode, said the vulnerability is the latest example of an instance of an open repository for building software that has been shown to be potentially vulnerable to an attack on a software supply chain that could theoretically impact any number of downstream applications and projects, including Kubernetes, Angular and platforms and services provided by Uber and LinkedIn.

A Custom Actions capability that enables application development teams to create their own workflows presents any cybercriminal attempting to compromise of software supply chain with a tempting target, noted Pticha. A few changes to lines of code in a workflow can translate into thousands or even millions of lines of code, many of which an organization may never detect. Out of 3.4 million workflows examined by Cycode, nearly all (99%) make use of one or more Custom Action.

Cycode has previously identified dozens of vulnerabilities in open source projects by mainly focusing on vulnerabilities within workflows. This latest research shows those vulnerabilities extend to indirect dependencies, such as Custom Actions, noted Pticha.

Each DevOps team should review its own workflows for similar vulnerabilities at a time when more cybercriminals than ever are intent on compromising software supply chains. While many organizations have embraced DevSecOps workflows to improve application security, there is a natural tendency to overlook vulnerabilities that might exist in the workflows used to build and deploy software. The challenge is that DevSecOps workflows are still immature. A recent survey of 500 U.S. CISOs, AppSec directors and DevSecOps team members conducted by Cycode found 78% admitted application security attack surfaces are unmanageable, with 90% acknowledging relationships between their security and development teams need to improve.

It’s not apparent if the vulnerability discovered by Cycode was actually ever exploited, but as most cybersecurity professionals know, if it can be imagined, someone has tried it. As such, any organization that uses Bazel might be well-advised to conduct a code review.

In the meantime, it’s already apparent that regulations pertaining to securing software supply chains are only going to become more stringent in the months ahead. In the wake of the executive order from the Biden administration requiring federal agencies to lock down their software supply chains, it’s now only a matter of time before similar requirements are baked into legislation and various other regulations are implemented. The challenge and the opportunity now is to get ahead of this issue before a mandate with a hard deadline that can’t be ignored winds up disrupting the entire software development life cycle.

February 1, 2024
Dynatrace Extends Data Reach and Scope of Observability Platform

At its Perform 2024 event today, Dynatrace unfurled a Dynatrace OpenPipeline that makes it possible to apply analytics to multiple types of data sources in real time.

The company also unveiled a Data Observability offering that can be used to vet the quality and lineage of data being exposed to the Davis artificial intelligence (AI) engine at the core of the Dynatrace observability platform to reduce false positives that otherwise might generate an alert in addition to helping reduce the volume of data that might need to be stored.

Finally, Dynatrace announced it is starting today extending the reach of its observability platform to the large language models (LLMs) that are used to create generative AI platforms. That capability will, for example, make it simpler to monitor the consumption of tokens that are used to provide access to these models.

Steve Tack, senior vice president for product for Dynatrace, said Dynatrace OpenPipeline will enable organizations to streamline the collection of data in a way that will enable them to apply observability more broadly by applying stream processing algorithms to petabytes of data.

Scheduled to be available in 90 days, the Dynatrace OpenPipeline capability enables IT teams to ingest and route observability, security, and business events data from any source and in any format at the point of ingestion, including unstructured data that is automatically converted into a usable format. That data can then be enriched to enable deeper analytics.

It also provides IT teams with more control over which data they analyze, store or exclude from analytics, which in turn helps reduce the total cost of observability, noted Tack.

Finally, it presents IT teams with the ability to apply more customizable security and privacy controls to how that data is employed, he added.

Dynatrace is pursuing a multimodal approach to AI that spans predictive, causal and generative models. Collectively, that approach makes it simpler to identify the root cause of issues, identify anomalies that might disrupt services and streamline incident management by, for example, providing summarizations of events in a natural language format.

It’s not clear how broadly observability will be applied beyond the data collected to manage DevOps workflows and other IT processes, but it’s clear there is a high correlation between IT events and business outcomes as organizations become more dependent on software. As AI becomes more pervasively employed, it should become simpler to apply analytics to a much wider range of types of data to surface the relationship between IT events and business processes. In effect, Dynatrace is making it simpler to apply best data engineering practices to collect, manage and analyze that data, noted Tack.

In the meantime, DevOps teams should revisit how their pipelines are currently constructed to make it simpler to capture all relevant data. As critical as telemetry data collected from the DevOps platform is to ensure application development and delivery occurs as fast as possible, that data is only one factor in a larger equation. The challenge and the opportunity now is determining how best to apply AI to correlate it all.

January 31, 2024
How to Make the Most of In-House Software Development

Let’s be blunt: Maintaining an in-house software development team can be tough. You must hire skilled developers – which is no easy feat in today’s economy, where talented programmers remain in short supply – and then manage them on an ongoing basis. You must also ensure that your development team is nimble enough to respond to changing business needs and that it can adapt as your technology stack evolves. Given these challenges, it’s no surprise that most organizations now outsource application development instead of relying on in-house teams.

But I’m here to tell you that just because in-house development can be hard doesn’t mean that outsourcing is always the best approach. On the contrary, IT organizations that choose to invest in in-house development for some or all the work can realize lower overall costs and a competitive advantage by creating domain-specific expertise. Keeping development in-house can help organizations address unique security requirements and maintain full control over the development lifecycle and roadmaps. For businesses with specialized technology, security and operational needs, in-house development is often the best strategy.

Managing an in-house development team presents some steep challenges. At Komprise, we have refined several practices to keep our team efficient and productive, even in a business environment that is constantly changing.

Scaling Up

Scaling teams up is a key challenge for in-house development teams. Finding skilled developers to grow a team can be very difficult, especially when working with a bespoke technology stack.

There is no simple solution to this challenge, but there are steps you can take to maximize your ability to find and hire development talent. For example, we invest significantly in engaging with college students, allowing us to identify promising developers while they are still in training.

At the same time, we invest in upskilling our developers who are already on our team so they can take on additional responsibilities. We train our engineers in the latest cloud development and security skills and knowledge. The notion of embedding security into our designs and practices is fundamental to what we do. We also rotate engineers between different teams so they learn new technologies that are important to our business. This strategy allows us to align the work for every developer with their interests and to build reusable skills within our teams. We also hold a technical brown bag three times per month where we cover issues like development for cloud and how it differs from on-premises due to costs or how to design for performance and scalability.

Focus on Customer Value

Figuring out which features customers want most is a constant challenge. To address it, we quantitatively track how our customers use our product – which functionality they use most often, for example, and how usage patterns vary across different customer demographics. We evolve these metrics as we develop the product. Additionally, we identify customers who are “power users” and occasionally set up calls between them and our developers to gain additional insight into what customers want. Our marketing team also conducts customer advocacy interviews with our users to learn more about what they like and don’t like.

Looking at third-party applications and interfaces helps us gain perspective on how best to meet user needs, too. For example, we might examine how Wayfair or Amazon are evolving their UI constructs to inform how we could change our product interface in ways that better meet customer needs. We want our B2B product to be as easy to use as consumer products.

Invest in QA

Quality Assurance (QA) operations are distinct from development operations, but if you want a successful in-house development team, you need a great QA team, too. Our QA engineers complement our in-house developers by helping them to deliver the highest-quality product, while also strategizing over how best to handle scale and efficiency challenges. In addition, we’ve invested heavily in QA automation, allowing us to test our applications thoroughly while keeping our team lean and efficient. This ensures that as our product feature set expands, our ability to test the entire product does not increase and we can maintain a monthly release cadence. We use test harnesses to simulate error and failure conditions, by injecting failures into the system or making our network experience a brownout or a blackout. You can’t automate every software test, but you can automate most of them, and QA automation is one of the key ingredients in effective development operations.

Leverage AI Strategically

AI is not the solution to every development challenge, but when used properly, AI can accelerate development and help in-house developers work more efficiently. Using AI tools to churn out code has become a hot use case for AI in development since the introduction of solutions like Copilot. AI can be a very useful solution, but the quality of the results it delivers hinges on the quality of the data it ingests. Inhouse development teams working on AI applications have much to consider from the data perspective. To leverage unstructured data, they need ways to find it across data silos, enrich it with new metadata as needed to support search and leverage AI tools like Amazon Macie and Rekognition to further refine the data.

Optimizing In-House Development for the Long Term

The importance of keeping in-house development teams happy and productive is likely only to increase as the tasks they work on grow more complex and as new paradigms, like those driven by AI, change the way developers work. The more IT organizations and enterprises can upskill their existing developers and empower them with the right tools and processes to succeed, the better they can leverage their teams to build products and features that bring value to the business.

January 31, 2024
Anima Adds Ability to Personalize Generative AI Code

Anima today revealed is has added an ability to personalize the code its generative artificial intelligence (AI) platform creates based on how an application is described using tools from Figma and Adobe.

That capability makes it possible for the code being generated to resemble the coding style of an organization or specific developer more closely.

Anima CEO Avishay Cohen said the company developed this capability to reduce the editing time that is otherwise required when trying to embed code generated by a large language model (LLM) within an application that has a well-defined coding methodology.

The platform that Anima provides is based on a mix of LLMs and heuristics that the company developed to generate code. In this case, the code being generated is written in React or HTML to make it simpler to build an application’s front end. In contrast, a general-purpose LLM such as ChatGPT is not optimized for creating these types of graphical applications.

Developers no longer need to worry about, for example, making sure each pixel is perfectly placed because the Anima platform automates that part of the application development process, including adding responsive behavior, animations and logic, noted Cohen. In addition, customized instructions may be applied to an entire project or even a specific component.

In effect, the platform enables backend developers to automatically create a front-end for their application from a description in tools provided by Figma or Adobe. As a result, developers can allocate more time to writing business logic and optimizing application performance, said Cohen.

Later this year, Anima will integrate its platform with GitHub and other continuous integration/continuous delivery (CI/CD) platforms as part of an effort to extend the reach of the platform across an entire codebase, he added.

There is, of course, already no shortage of generative AI tools for writing code, but the degree to which they have been incorporated into DevOps workflows varies from one organization to the next. Much of the code created using platforms such as ChatGPT can vary widely in terms of quality. These platforms were trained using code collected from across the web so it’s not uncommon for the code generated to include known vulnerabilities that DevOps teams need to scan before incorporating into a build. In other cases, the code generated might simply break when installed.

Regardless of these issues, however, the amount of code being generated by machines is only going to increase, especially as more LLMs that are specifically trained to create code based on examples that have been closely vetted become more widely available.
In the meantime, developers who never especially enjoyed building the visual front ends of applications can now focus more of their time on tasks they prefer. Alternatively, developers who specialize in the front ends of applications will find that much of the toil involved will soon be automated in a way that should provide more time for them to create customized experiences.

One way or another, the overall pace at which applications are built is about to exponentially increase. The challenge now will be finding ways to take advantage of AI to enable DevOps teams to keep pace.

January 30, 2024
Using LLMs to Automate Pipeline Conversions From Legacy to Tekton

There have been many technological advancements in the market today, but the main hindrance is the cumbersome process of switching from the existing technology/framework to the new one. This is where teams and organizations are left behind in the tech curve. In the DevOps landscape, CI/CD pipelines are the backbone of DevOps, and how you work with them largely dictates your DevOps efficiency.

CI/CD pipelines, too, like other major technologies and frameworks in the past, have seen various evolutions; the latest among them is being made reusable in an attempt to standardize CI/CD. However, here too, there are several cons:

1. The pipelines are not proprietary to end-user enterprises and belong to the DevOps platforms which are not open-source
2. Migrating to these platforms and pipelines is a huge task
3. They may not be as efficient as depicted

Speaking of new advancements in technology, most might be familiar with Tekton for CI/CD pipelines: It is Google’s open source framework that is now a graduated CDF project. It redefines how pipelines are built (through reusable tasks) and these tasks are open source and community-vetted. They allow for pipeline authorship, and enterprises can re-use them across platforms that are compatible with Tekton, thus preventing vendor lock-in.

While this mitigates the first challenge of pipeline ownership and migrations, however, the same problem plagues DevOps teams – transitioning from existing legacy technologies/frameworks to newer, much more capable frameworks like Tekton.

However, what if there was a way to seamlessly automate your transition from legacy pipelines to cutting-edge, reusable Tekton pipelines without toil? This is precisely what the article aims to explore – automating the conversion of Yaml scripts of existing pipelines to Tekton Yaml scripts.

Let us consider the three most popular CI/CD platforms for this use case – Jenkins, GitLab and Azure DevOps. Before we proceed to the proposed approach to achieve this (which is detailed in the second half of this article), let us first look at the limitations of Jenkins, GitLab and Azure Pipelines and why one should convert.

Common Limitations of Jenkins, Azure and GitLab Pipelines

Resource Intensive: Legacy pipelines can be resource-intensive, especially for larger organizations or projects. Managing server resources, optimizing configurations and ensuring sufficient hardware can be a challenge.
Complex Setup: Setting up and configuring Jenkins, GitLab and Azure DevOps can be complex, particularly for self-hosted instances. This complexity may require experienced administrators and substantial time investment.
Plugin and Integration Compatibility: All three platforms may face compatibility issues with certain plugins or integrations.
Scaling Challenges: Scaling in organizations, especially when dealing with multiple microservices, necessitates a shift from individualized scaling to a template-based approach. Failing to do so leads to a chaotic increase of pipelines, undermining standards and organizational processes.
Costs: While both Jenkins and GitLab offer free and open-source versions, some advanced features or capabilities may only be available in higher-tier paid plans. This can lead to cost considerations at scale.
Customization Complexity: These platforms can be complex to customize workflows and integrate custom scripts as they require advanced scripting knowledge.
User Interface Complexity: Though they have feature-rich interfaces, it can sometimes be overwhelming for new users to navigate the platforms and find specific settings or options.
Limited Native Integration & Plugins: The native integrations of Jenkins, GitLab and Azure may not cover the full spectrum of tools and services a team may need. Additional integration efforts or third-party tools may be required to bridge gaps in the development workflow.

As can be seen in the above limitations, many are common including scalability challenges, being resource intensive, limited integrations etc. All the challenges boil down to one common denominator: Complex pipeline management at scale.

This is where a framework like Tekton can help tackle all the challenges at once, by just easing pipeline management: with its K8s-native pipelines that are reusable, open source and tasks that are community-vetted.

Tekton Pipelines: Advancing CI/CD with Kubernetes-Native Automation

Tekton, an open-source project, is rapidly gaining traction as a game-changer in the world of CI/CD pipelines. Its Kubernetes-native design is a standout feature, seamlessly integrating with Kubernetes clusters to harness its scalability and resource efficiency.

Furthermore, Tekton’s cloud-native roots ensure it can execute tasks in lightweight, ephemeral containers, optimizing resource utilization. The ability to declare CI/CD pipelines as code, coupled with GitOps practices, enhances automation and reproducibility.

How are Tekton Pipelines Different?

Kubernetes-Native Automation: Tekton pipelines are deeply integrated with Kubernetes, utilizing Custom Resources and Operators to define and execute CI/CD workflows.

Declarative and Modular: These pipelines are defined declaratively using YAML manifests, promoting version control, collaboration and code reviews. The modular design of tasks and pipelines enables teams to create reusable components for building, testing and deploying applications.

Containerization and Isolation: Each task in a Tekton pipeline runs within a dedicated container, ensuring isolation and reproducibility of the build and deployment environment.

Event-Driven Architecture: Tekton pipelines can be triggered by various events, such as code commits, pull requests, or external events, providing a responsive and event-driven CI/CD process.

Scalability and Efficiency: Tekton pipelines leverage Kubernetes’ inherent scalability, enabling efficient execution of tasks across a dynamic pool of worker nodes.

Visibility and Observability: They offer built-in monitoring and logging, allowing teams to gain insights into pipeline execution, track progress and diagnose issues.

Integration and Extensibility: Tekton pipelines can be easily extended with custom tasks and integrations, enabling teams to connect with various tools, services and cloud platforms.

Cloud-Native Best Practices: By embracing Tekton pipelines, organizations align with cloud-native best practices, promoting the use of Kubernetes and containerization for streamlined application delivery.

Why Transition From Jenkins, GitLab, and Azure Pipelines to Tekton Pipelines?

Migrating from Jenkins, GitLab, or Azure pipelines to Tekton pipelines can be a strategic choice, especially for organizations deeply entrenched in Kubernetes and cloud-native methodologies.

Optimize Kubernetes-Centric Workflows: Projects tightly integrated with Kubernetes may find Tekton pipelines more aligned with their ecosystem.

Accelerate Cloud-Native DevOps: Organizations aiming to embrace a cloud-native approach and leverage Kubernetes infrastructure.

Performance and Scalability: Tekton pipelines run on clusters that can dynamically be created and destroyed according to demand, thus taking resource optimizations to the next level.

Cloud-Native Best Practices: Best practices, such as containerization, declarative configuration and infrastructure-as-code are a natural fit due to their Kubernetes-native design.

Proposed Workflow for Automating Pipeline Conversions at Scale

The overarching objective of this workflow is to facilitate a seamless conversion process using large language models (LLM) without delving into the intricacies of fine-tuning but rather using the benefits of prompt engineering. Central to this approach is the use of the chat context and the strategic application of roles for LLM models to establish context. Along with this, sample pipelines are leveraged to train and fine-tune the model to define how the corresponding YAMLs of all these platforms look for any given pipeline.

The use of prompts and instructions tailored to fit the use case of generating contextual pipeline YAML and conversion of Jenkins/Gitlab pipelines to Tekton pipelines makes this workflow possible. We maintain a context and a contextual mapping of real-world examples and the most appropriate prompt designs to produce the most accurate responses. The role of users in this context adds weight and further refines the response received.

However, before proceeding into details and examples, let’s set the base for what exactly generative AI means and its context in our use case:

Generative AI and LLM for Automating YAML Script Conversions

Generative AI, such as LLMs, create content like text, benefiting from patterns in large datasets. Large language models (LLMs), with billions of parameters, excel in generating human-like text by understanding language structures. They have broad applications, including natural language understanding, summarization, translation and content generation, promising automation and human-like interactions with AI.

Adapting the Model to Solve Real-world Use Cases

Fine-tuning and prompt engineering are two common methods used to train large language models (LLMs) like GPT-3, BERT and others. These methods help adapt pre-trained models for specific tasks or generate contextually relevant responses. Both fine-tuning and prompt engineering play crucial roles. Fine-tuning helps the model comprehend complex use cases, while prompt engineering provides detailed requirements, extracting the best results from the model.

Why Prompt Engineering?

Prompt engineering stands out as a highly advantageous approach in specific use cases where precision, control and customization over AI model behavior are paramount. This method empowers developers and users to meticulously design input prompts, effectively guiding AI models to produce contextually relevant and desired responses.

Prompt engineering is both an AI engineering technique for refining large language models (LLMs) with specific prompts and recommended outputs and the term for the process of refining input to various generative AI services to generate text or images.

The process of prompt engineering to fit our use case includes :

Defining the goal: The first step in the process of AI prompt engineering involves setting a clear objective.

Crafting the initial prompt: With the goal in mind, it’s time to draft an initial prompt. This could take the form of a question, a command or even a scenario, depending on the goal.

Testing the prompt: The initial prompt is then input into the language model, and the response is analyzed.

Analyzing the response.

Refining the prompt: With the insights gathered from testing and analysis, it’s time to revise the prompt. This could involve making it more specific, adding more context or changing the phrasing.

Iterating the process: The testing, analyzing and refining steps are repeated until we are satisfied that the prompt consistently guides the model toward generating the desired response

To conclude, here’s an example of typical YAMLs from Jenkins, GitLab and Azure DevOps, and how the same YAML looks when converted to a Tekton YAML. This goes a long way in facilitating teams to finally make a jump from their existing pipelines to cutting-edge reusable pipeline frameworks:

Jenkins YAML

GitLab YAML

Azure YAML

Converted Tekton YAML

January 30, 2024
Snyk Acquires Helios to Extend Reach of ASPM Platform

With its acquisition of Helios, Snyk plans to add an ability to capture application runtime data to extend the capabilities of its application security posture management (ASPM) platform.

Manoj Nair, chief product officer for Snyk, said Snyk AppRisk will soon provide real-time insights into runtime environments using a Helios observability platform that provides them with deeper insights into issues that need to be resolved. That capability will provide developers with additional context as more responsibility for application security continues to shift left toward application development teams, he added.

Armed with that insight, it then becomes simpler to prioritize remediation efforts based on the level of risk a vulnerability actually represents to the organization, said Nair. That’s critical to close a longstanding divide between cybersecurity and application development teams that, in the absence of any real ability to determine the severity of a vulnerability, results in developers wasting what limited time they have to allocate to remediation, he noted.

Nair said the overall goal is to enable organizations to deploy more secure applications while minimizing adverse impacts on developer productivity.

Snyk last year acquired Enso Security to add an ASPM platform to its portfolio that serves as the foundation upon which Snyk AppRisk was built. It also includes Insights, a Snyk tool that makes use of multiple types of artificial intelligence (AI) models to identify, prioritize and fix vulnerabilities.

There’s often not a lot of love lost between cybersecurity teams and application developers who typically don’t have a lot of cybersecurity expertise. Most of the issues that cybersecurity teams are tasked to address start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix.

Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving, but there is still a long way to go before application security truly improves. The one thing that is certain is the level of accountability for vulnerabilities is only going to rise as more stringent regulations go into effect in the months and years ahead.

In the meantime, DevSecOps teams should assume there will be many more vulnerabilities to remediate. Developers are increasingly using generative AI tools to write code. The challenge is general-purpose large language models (LLMs), such as the one used to drive ChatGPT, were trained using examples of code of varying quality collected from across the web. A lot of the code these platforms generate, not surprisingly, contains vulnerabilities that many developers will not immediately recognize without the aid of some type of scanning tool.

At the same time, cybercriminals are becoming more efficient at discovering and exploiting vulnerabilities that exist in applications that have already been deployed in production environments. DevSecOps teams should expect that, as a result, more zero-day vulnerabilities requiring immediate attention will soon be discovered.

One way or another, the percentage of time allocated to application security issues is only going to increase. The only thing left to determine is how best to go about reducing the time and effort needed to make applications as secure as possible.

January 29, 2024
SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

SmartBear this week revealed it has acquired Reflect, a provider of a no-code testing platform for web applications that leverages generative artificial intelligence to create and execute tests.

Madhup Mishra, senior vice president of product marketing at SmartBear, said the platform Reflect created will initially be incorporated into the company’s existing Test Hub platform before Reflect’s generative AI capabilities are added to other platforms.

Reflect provides access to a natural language interface to create tests using multiple large language models (LLMs) that it is designed to invoke. It can also understand the intent of a test to understand what elements to test regardless of whether, for example, a button has been moved from one part of a user interface to another, said Mishra. Test step definitions, once approved, can also be automatically executed using scripts generated by the platform.

SmartBear has no plans to build its own LLMs, said Mishra. Rather, the company is focusing its efforts on providing the tools and prompt engineering techniques needed to effectively operationalize them, he added.

Reflect is the tenth acquisition SmartBear has made as part of an effort to provide lightweight hubs to address testing, the building of application programming interfaces (APIs) and analysis of application performance and user experience. Last year, the company acquired Stoplight to gain API governance capabilities.

Rather than building a single integrated platform, the company is focused on providing access to lightweight hubs that are simpler to invoke, deploy and maintain, said Mishra. The overall goal is to meet IT teams where they are versus requiring them to adopt any entirely new monolithic platform that requires organizations to rip and replace every tool they already have in place, he said.

There is little doubt at this point that generative AI will have a profound impact on application testing in a way that should ultimately improve the quality of the applications. As the time required to create tests drops, more tests will be run. Today, it’s all too common for tests not to be conducted as thoroughly as they should be simply because either a developer lacked the expertise to create one or, with a delivery deadline looming, they simply ran out of time.

Naturally, the rise of generative AI will also change how testing processes are managed. It’s not clear how far left generative AI will push responsibility for testing applications, but as more tests are created and run, they will need to be integrated into DevOps workflows.

Of course, testing is only one element of a DevOps workflow that is about to be transformed by generative AI. DevOps teams should already be identifying manual tasks that can be automated using generative AI as part of an effort to further automate workflows that, despite commitments to automation, still require too much time to execute and manage. Once identified, DevOps teams can then get a head start on redefining roles and responsibilities as generative AI is increasingly operationalized across those workflows.

January 26, 2024
New Relic Adds Ability to Correlate IT Events to Business Processes

New Relic this week added an ability to enable DevOps teams to better understand the potential business impact any change to an IT environment might have.

Manav Khurana, chief product officer for New Relic, said New Relic Pathpoint adds a dashboard to the company’s observability platform through which business metrics can be collected alongside telemetry data. That data is collected either via connectors provided by New Relic or via a metrics application programming interface (API) that IT teams can invoke.

IT teams can use that API to connect to custom applications or an end-to-end business process, noted Khurana.

All that data is then modeled alongside DevOps telemetry data to provide insights into the impact any change might have on the business in real-time, he added. That approach provides the added benefit of making it easier to strategically align the management of applications, services and infrastructure by business function, noted Khurana.

In the near future, New Relic will also extend the natural language capabilities it is currently previewing to New Relic Pathpoint, he said.

Longer term, New Relic is working toward making it possible to model how proposed changes to business processes will impact IT environments, added Khurana.

Business and IT leaders intuitively understand that every business event creates a corresponding IT event, but most organizations manage those processes in isolation. New Relic Pathpoint presents an opportunity to close a divide between IT teams and the rest of the business that has plagued organizations for decades.

It may be a while before advances in data analytics and AI eliminate that divide completely, but creating a common set of metrics for managing business and IT processes is a crucial first step.

In the meantime, DevOps teams, in addition to accelerating the pace at which applications can be built and deployed, are being asked to employ observability platforms such as New Relic One to minimize disruption to the business. Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications using open source agent software, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate IT and business events.

It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of predefined but often conflicting metrics. Observability platforms, however, unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue, hopefully before any catastrophic disruption can occur.

January 25, 2024