devopsy.kinsta.cloud

Category: DevOps Toolbox

  • CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI today added a release orchestration capability to its namesake continuous integration/ continuous delivery (CI/CD) platform to give developers more control over application deployments.

    CircleCI CTO Rob Zuber said a CircleCI releases capability provides development teams with the ability to release a controlled subset of their code in a live production environment in a way that provides immediate feedback on how that code is performing. That level of visibility can then be used to determine whether that code might need to be rolled back using automation tools embedded in the CircleCI CI/CD platform, he added.

    In the absence of that capability, noted Zuber, it takes DevOps teams, on average, 45 minutes to an hour to manually roll back an application.

    Initial platforms supported by CircleCI releases are Kubernetes and Amazon SageMaker. CircleCI releases is also compatible with the open source Argo CD platform that CircleCI integrated its platform with last year.

    CircleCI also plans to add support for blue-green deployments later this year, enabling DevOps teams to deploy one application version more gradually to replace another.

    The way CD is managed often varies widely from one organization to another. In highly regulated industries, CD is typically managed by a central team to ensure compliance requirements are met. In other instances, developers are directly responsible for building and deploying their code. Regardless of approach, CircleCI enables organizations to define a set of guardrails to ensure best practices are observed, noted Zuber. In effect, each organization can implement a set of checks and balances that are aligned to their specific needs, he added.

    As DevOps continues to evolve, more organizations want the ability to control deployments at a more granular level by, for example, only making a new application or an update available to a select number of users. Once deployed, developers need a more holistic view into not just how that application is performing but also how it impacted the business, said Zuber. If, for example, the number of logins declines after an update, a developer needs the information to determine whether that update should be rolled back as quickly as possible, he added.

    It’s not clear how many organizations are managing the entire CI/CD workflow on an end-to-end basis. While most DevOps teams make extensive use of CI to build an application, the deployment of applications is still often managed manually. However, as CD capabilities become simpler to employ across platforms with standard interfaces, the number of organizations automating CD should steadily increase. In fact, that capability will soon prove essential as, thanks to the rise of generative artificial intelligence (AI), the pace at which applications are being built only continues to accelerate.

    In the meantime, each organization will need to determine how closely it wishes to integrate CI and CD workflows. However, the more tightly integrated these processes become, the simpler it becomes for developers to assume full responsibility for building and maintaining the software they create.

  • Flox CLI Tool Makes Managing Custom Developer Environments Simpler

    Flox CLI Tool Makes Managing Custom Developer Environments Simpler

    Flox today made generally available an open source command line interface (CLI) for a namesake tool that enables developers to more easily spin up multiple custom development environments.

    At the same time, the company revealed at the 21st annual Southern California Linux Expo (SCALE 21) that it is now providing access to FloxHub, a free repository for sharing development environments across teams.

    Flox is based on the same declarative framework used to invoke the Nix package management and configuration tool. It allows developers to create environments that contain everything they need to build software, including automatic creation of a software bill of materials (SBOM).

    Ross Turk, head of marketing and developer relations for Flox, said that approach provides developers with a framework for managing multiple development environments that they can spin up using the same methods commonly used to invoke the package managers versus having to master a less familiar approach to manage development environments, he added.

    That capability makes it simpler for developers to both replicate development environments across machines and, when needed, dynamically switch between projects in a way that can be continuously audited by a centralized DevOps team. Instead of requiring a DevOps team to apply the same rigid standard environment across all development projects, each developer is still free to customize their environment based on their personal preferences.

    In addition, developers trying to fix a bug can also now easily reproduce the development environment they were using at the time they were writing the code they needed to review.

    DevOps teams are increasingly finding themselves caught between competing agendas. Many IT leaders are driving the adoption of platform engineering methodologies to centralize the management of DevOps workflows in the hopes of increasing developer productivity and reducing total costs. Conceptually, developers would prefer to have more backend processes managed by those teams, but not to the point where it forces them to use a development environment that has been defined for them. Each developer typically prefers to customize their development environment as the project evolves.

    Arguably, one of the primary reasons developers embrace DevOps is that it gives them more control over their development environments. The challenge is that as each team defines its own DevOps workflow, organizations often later discover they are licensing redundant DevOps tools and platforms.

    In the meantime, it’s not clear to what degree platform engineering might boost developer productivity. It no doubt will reduce the amount of time developers spend managing backend processes, but having that extra time doesn’t directly equate to better code being delivered faster. Writing code is as much an art as science, so it creates levels of inspiration that don’t always occur whenever a developer starts to write code. Instead, platform engineering creates more opportunities for inspiration to strike because they are not spending time on other tasks. At the very least, it should provide more time to run tests on the code that is produced.

    One way or another, as application development continues to evolve, most organizations will find the middle ground that best suits their needs. The challenge now is reducing the amount of time between now and when that goal is eventually achieved.

  • Applying AI/ML to Continuous Testing

    Applying AI/ML to Continuous Testing

    Artificial intelligence (AI) and machine learning (ML) can play a transformative role across the software development lifecycle, with a special focus on enhancing continuous testing (CT). CT is especially critical in the context of continuous integration/continuous deployment (CI/CD) pipelines, where the need for speed and efficiency must be balanced with the demands for quality and security. AI/ML contributes by automating complex tasks, predicting potential issues before they occur and providing actionable insights, thereby reducing manual efforts and enabling more strategic use of human resources.
    Moreover, the application of AI/ML extends beyond mere automation of tests. It encompasses the capability to learn from data, adapt to new information, and improve over time. This ability is invaluable for identifying patterns, anticipating vulnerabilities and optimizing testing strategies. In quality assurance, AI-driven tools can predict areas most likely to fail and tailor testing efforts accordingly. In security, ML algorithms can detect anomalies that signify potential threats, while in operations, AI can enhance feedback mechanisms, leading to more resilient and responsive systems.

    AI/ML for Continuous Testing

    Here’s how AI technologies can be applied to reduce bottlenecks associated with testing activities across various testing activities:

    1. Requirements Analysis
    • Explanation: Ensures test scenarios align with business requirements and user needs.
    • Bottleneck: Misinterpretation or incomplete analysis can lead to inadequate test coverage.
    • AI/ML Solution: NLP can automate the extraction and interpretation of requirements, ensuring comprehensive and accurate test coverage.

    2. Test Strategy
    • Explanation: Outlines the testing approach, objectives, and resources.
    • Bottleneck: An unclear strategy may lead to inefficient testing efforts and resource allocation.
    • AI/ML Solution: AI can analyze historical data to suggest the most effective test strategies and predict resource needs.

    3. Test Plans
    • Explanation: Detailed documents guiding the testing process, timelines, and responsibilities.
    • Bottleneck: Inflexible plans can struggle to adapt to project changes, causing delays.
    • AI/ML Solution: Machine learning algorithms can suggest adjustments to test plans based on ongoing project developments and past outcomes.

    4. Test Cases
    • Explanation: Specific conditions under which a test is executed.
    • Bottleneck: Time-consuming development and significant effort to maintain.
    • AI/ML Solution: AI can automate the generation of test cases from requirements documents, improving efficiency and coverage.

    5. Test Scripts
    • Explanation: Automated scripts that execute test cases.
    • Bottleneck: Script development and maintenance can be resource-intensive.
    • AI/ML Solution: AI can generate and update test scripts based on changes in the application or test cases, reducing maintenance effort.

    6. Test Data
    • Explanation: Data sets used during testing to simulate real-world scenarios.
    • Bottleneck: Creating, managing, and maintaining accurate test data is challenging.
    • AI/ML Solution: AI can automate the generation and management of test data, ensuring relevance and variety.

    7. Test Environment
    • Explanation: The setup where testing is conducted mirrors production environments as closely as possible.
    • Bottleneck: Configuration and maintenance of test environments are complex.
    • AI/ML Solution: AI can predict and configure optimal test environments based on test requirements, reducing setup time.

    8. Coordination with Dependent Systems
    • Explanation: Ensuring the system under test interacts correctly with databases and other applications.
    • Bottleneck: Dependency management can cause delays.
    • AI/ML Solution: AI can automate the detection and resolution of integration issues, enhancing coordination efficiency.

    9. Test Environment Setup
    • Explanation: Configuring infrastructure and tools necessary for testing.
    • Bottleneck: Setup complexity and resource contention lead to delays.
    • AI/ML Solution: AI algorithms can optimize environment setup, automatically adjusting resources as needed.

    10. Test Campaign Setup
    • Explanation: Organizing and scheduling a series of test executions.
    • Bottleneck: Requires careful planning and can be hindered by resource limitations.
    • AI/ML Solution: AI can assist in scheduling and prioritizing test campaigns based on risk and impact analysis.

    11. Test Execution
    • Explanation: The process of running test cases and scripts, both automated and manual.
    • Bottleneck: Time-consuming, particularly for manual tests.
    • AI/ML Solution: AI can prioritize test execution and identify flaky tests, streamlining the process.

    12. Test Verdict Reporting
    • Explanation: Determining and reporting the outcome of test executions.
    • Bottleneck: Manual verdict determination can be slow.
    • AI/ML Solution: AI can automatically interpret test outcomes, speeding up reporting.

    13. Logging of Data
    • Explanation: Recording data relevant to the test for further analysis.
    • Bottleneck: Extensive data collection can overwhelm resources.
    • AI/ML Solution: AI can intelligently filter and log pertinent data, reducing noise.

    14. Test Result Analysis
    • Explanation: Analyzing test outcomes to identify defects and issues.
    • Bottleneck: Requires significant time and expertise.
    • AI/ML Solution: ML algorithms can quickly identify patterns and anomalies in test results, highlighting potential issues.

    15. Test Result Reporting
    • Explanation: Communicating findings to stakeholders.
    • Bottleneck: Compiling reports is time-intensive.
    • AI/ML Solution: Automated reporting tools powered by AI can generate insightful and comprehensive reports quickly.

    16. Waiting for Resource to Fix Failed Tests
    • Explanation: Downtime while awaiting fixes for identified issues.
    • Bottleneck: Halts testing progress.
    • AI/ML Solution: AI can predict which areas might fail and propose potential fixes

    Challenges

    Applying AI/ML to software testing activities offers numerous advantages but also introduces several challenges. Addressing these problems requires a combination of technical solutions, process adjustments, and cultural changes.

    1. Lack of Intuitive Understanding of the Application Being Tested
    • Problem: AI/ML models may not fully grasp the application’s context or the nuances of its functionalities, leading to less effective test scenarios.
    • Solution: Enhance AI models with richer contextual data and incorporate feedback loops where testers can refine and adjust AI-generated test cases. Employing techniques like reinforcement learning can also help AI models better understand application contexts over time.

    2. Repeatability and Consistency Between Test Sessions
    • Problem: AI-driven tests may generate different outputs for the same input over different sessions, complicating test consistency and traceability.
    • Solution: Implement versioning for AI models and their training data, ensuring consistency across test sessions. Use deterministic approaches in conjunction with AI to maintain a core of stable, repeatable tests.

    3. Lack of Understanding of the Tests Generated
    • Problem: Testers may find it challenging to understand or trust the rationale behind AI-generated test cases, impacting their ability to evaluate test outcomes effectively.
    • Solution: Incorporate explanations into AI/ML models to provide insights into their decision-making processes. Foster a culture of trust and understanding through education and transparency regarding how AI models operate.

    4. Test Coverage
    • Problem: There’s a risk that AI/ML might not adequately cover all testing scenarios, potentially missing critical defects.
    • Solution: Combine AI/ML with traditional testing methods to ensure comprehensive coverage. Regularly review and adjust the criteria used by AI/ML models to generate test cases, ensuring they align with evolving application features and risks.

    5. Compatibility with Different Test Tools
    • Problem: AI/ML models might not seamlessly integrate with existing testing tools and frameworks, limiting their utility.
    • Solution: Develop or use AI/ML solutions with extensive API support and integration capabilities. Work with tool vendors or contribute to open source projects to enhance compatibility.

    6. Acceptance by Teams
    • Problem: Testers and developers may be skeptical or resistant to AI-driven testing due to concerns about job displacement or mistrust in AI’s effectiveness.
    • Solution: Educate and involve teams in the development and implementation of AI/ML testing strategies. Demonstrate the value of AI/ML in augmenting their roles rather than replacing them, focusing on AI as a tool to tackle mundane tasks and allowing them to focus on more complex and rewarding work.

    7. Data Quality and Availability
    • Problem: AI/ML models require large amounts of high-quality data for training. Inadequate or poor-quality data can lead to ineffective testing.
    • Solution: Invest in data curation and generation strategies such as synthetic data creation to ensure models are well-trained.

    8. Continuous Learning and Adaptation
    • Problem: AI/ML models may become outdated as applications evolve.
    • Solution: Establish continuous learning mechanisms where models are regularly updated with new data and feedback, ensuring they remain relevant and effective.

    9. Ethical and Bias Considerations
    • Problem: AI/ML testing models might inherit or amplify biases present in their training data, leading to unfair or discriminatory outcomes.
    • Solution: Implement ethical guidelines and bias detection methodologies for AI/ML model development and use. Regularly audit models for biases and correct them as needed.

    By addressing these challenges with thoughtful strategies, organizations can maximize the benefits of AI/ML in testing activities while mitigating potential drawbacks, leading to more efficient, effective and trustworthy processes.

    Summary

    This blog explained use cases of artificial intelligence (AI) and machine learning (ML) within the realm of continuous testing of the software development life cycle. By harnessing the power of AI/ML, we’ve seen how organizations can significantly enhance their development processes, making them more efficient, secure and responsive to user needs. The exploration of specific AI/ML applications across various activities has provided a blueprint for automating and optimizing tasks that traditionally required significant manual effort.

  • Sumo Logic Eliminates Ingest Fees for Observability Log Data

    Sumo Logic Eliminates Ingest Fees for Observability Log Data

    Sumo Logic this week announced it will no longer charge a fee for ingesting log data into its observability platform to encourage DevOps teams to apply analytics more deeply.

    Michael Cucchi, vice president of product marketing for Sumo Logic, said the Sumo Logic Flex Licensing plan eliminates what amounts to a tax for using an observability platform. Flex Licensing is being made available immediately to new customers and will be offered to existing Sumo Logic customers later this year. There are no hidden monthly charges, feature restrictions, performance tradeoffs or user limitations being applied under the plan.

    The licensing plan only applies to log data, but DevOps teams will be able to ingest all structured, semi-structured and unstructured data for a lower cost that Sumo Logic is working to store more efficiently, said Cucchi. The overall goal is to make available a disruptive approach to licensing that lowers the total cost of observability, he added.

    Storing log data is going to be increasingly critical as organizations begin to apply multiple types of artificial intelligence (AI) models to further automate IT operations, he added. Those AI models promise to make observability platforms more accessible because algorithms will be able to surface issues that need to be addressed. Historically, the value of an observability platform has been tied to how proficient a DevOps team became when using its query language.

    IT teams that have adopted observability platforms have been, to varying degrees, limiting the amount of data they collect and retain to keep storage costs from exploding. The challenge is that as DevOps teams deploy more microservices-based applications, the amount of log data generated has exploded. Determining the root cause of any issue involving those applications can be problematic if log data isn’t readily available. Log data is, after all, the atomic unit for observability, noted Cucchi.

    In general, IT environments are becoming too complex for humans to manage without the aid of observability platforms augmented by AI models, noted Cucchi. Each application environment is fairly unique, so it is pivotal for those AI models to be exposed to as much data as possible to ensure optimal results.

    It’s not clear whether observability platforms might one day replace the need for many of the monitoring tools that IT teams rely on today to track a set of pre-defined metrics. However, one thing that is certain is that observability platforms, at the very least, present an opportunity to rationalize some of those tools. The biggest challenge is finding ways to fund the acquisition of an observability platform in the first place, which then creates an opportunity to consolidate those tools later.

    Given the complexity of highly distributed computing platforms, it’s only a matter of time before most IT teams have some type of observability capability in place. Of course, observability has always been a core DevOps tenet. The trouble is that the tools being used to achieve it are legacy monitoring platforms that don’t provide the level of depth required to successfully manage modern application environments.

    Image source: Joshua Sortino via Unsplash.

  • appCD Launches Platform to Securely Provision Cloud Infrastructure

    appCD Launches Platform to Securely Provision Cloud Infrastructure

    appCD this week launched a namesake platform that analyzes an application about to be deployed to automatically generate the code needed to provision the IT infrastructure required.

    Fresh from raising $6 million in seed funding, appCD CEO Sachin Aggarwal said that approach makes it possible to consistently create secure code for provisioning IT infrastructure versus requiring developers with little to no cybersecurity to manually write it.

    Instead, appCD reviews Python or Java code to understand intent, identifies dependencies and then infers application programming interface (API), service configuration, ingress/egress and other environment variables. Terraform code or Helm charts are then automatically generated based on the static analysis of the code that has been reinforced using artificial intelligence (AI) learning techniques.

    That approach also makes it simpler for platform engineering teams to centrally manage the provisioning of IT infrastructure using a set of pre-defined policies that are automatically implemented each time an application is deployed to ensure security by default, he added.

    DevOps teams can also use appCD to visualize the deployment environment before and after an application is deployed, said Aggarwal.

    While infrastructure-as-code (IaC) tools have accelerated the rate at which cloud infrastructure can be provisioned, they are also often the root cause of the security issues that plague cloud computing environments. Developers often misconfigure cloud infrastructure by, for example, inadvertently leaving ports open. The appCD platform reduces the potential such mistakes will be made, noted Aggarwal.

    That capability also eliminates the need to attach cybersecurity specialists to a DevOps team because issues are automatically resolved by the guardrails enforced by appCD, he added.

    In theory, at least, there may soon come a day when AI routinely improves the quality of the code being used to both build and deploy applications. The more the code used to train a large language model (LLM) is vetted, the more reliable the output becomes. In the meantime, platforms such as appCD are combining static analysis with AI reinforcement learning to achieve that same goal in a use case that is specific to generating code to provision IT infrastructure.

    Each DevOps team will naturally need to determine the best path forward, but as regulations pertaining to securing software supply chains become more stringent, it’s only a matter of time before organizations will be required to embrace DevSecOps workflows. In the meantime, DevOps teams should assume that given the probability cloud infrastructure has been misconfigured, it’s all but certain there will be multiple cloud security incidents. In fact, cybercriminals are actively scanning for misconfigurations that they have already created playbooks to specifically exploit in a matter of minutes.

    In the absence of being able to prevent all those issues from arising, the immediate priority becomes remediating as many issues as possible before cybercriminals exploit those vulnerabilities. However, it’s also important to draw a proverbial line in the sand to ensure that all cloud infrastructure being provisioned in the future is much more secure than it has tended to be thus far.

  • Copado Streamlines Custom Salesforce App Testing

    Copado Streamlines Custom Salesforce App Testing

    Copado today added a testing tool to its platform for managing DevOps workflows in Salesforce application environments that automatically creates scripts based on manual tests being conducted.

    Announced at the TrailblazerDX conference hosted by Salesforce, Copado Explorer enables DevOps teams to integrate those scripts into testing processes that can be repeated as required.

    David Brooks, senior vice president and lead evangelist for Copado, said the goal is to make it simpler for DevOps teams to add those tests to the regression tests that are incorporated into pipelines created using the Copado continuous integration/continuous delivery (CI/CD) platform.

    In addition, markup and annotation tools enhance collaboration by allowing non-technical subject matter experts to provide detailed feedback and insights to quality assurance and development teams as part of an effort to streamline communications between product owners, testers and developers. Testers without a technical background can use that capability to contribute to the creation and deployment of effective automated tests. That capability makes it possible to shift testing further left to incorporate the business teams that better understand how an application should function, said Brooks.

    The challenge is far too many organizations still overlook the importance of testing, noted Brooks. There is a tendency when using low-code tools to assume that not as much testing is required because the tools that generate code create a false sense of instant quality despite flaws that might not manifest themselves until an application is deployed, noted Brooks.

    Rather than constantly updating applications, more testing should improve the quality of the applications being built sooner. That’s critical because most organizations don’t have the time and resources needed to continuously iterate applications until they eventually arrive at what the business requires, said Brooks.

    It’s still early days so far as the level of DevOps maturity that organizations using the Salesforce platform to build and deploy custom applications have thus far attained, noted Brooks. However, just about every organization that licenses the software-as-a-service (SaaS) platform from Salesforce customizes those applications to better align them with their internal business processes, he added.

    Each organization will naturally need to determine to what degree they are prepared to deploy customer applications, but it’s clear it’s becoming simpler to build them. Late last year, Copado, for example, added generative artificial intelligence (AI) tools to make it easier to manage the DevOps workflows used to build these applications, which means the speed at which these apps are built and deployed is about to exponentially increase.

    Salesforce, of course, is only one of many SaaS platforms that organizations rely on to build and deploy custom applications. However, as one of the most dominant platforms, the pace at which custom applications are being built continues to increase, with a larger percentage of these applications being built by professional developers familiar with DevOps best practices.

    Eventually, those DevOps workflows will be extended to every kind of developer, but for now, most organizations building applications are looking for more consistent outcomes regardless of what type of tool is used to build them.

  • Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

    Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

    Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

    The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

    That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

    That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

    The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

    Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

  • Driving the DevOps Evolution: ArgoCD, Tekton and Seamless Migrations

    Driving the DevOps Evolution: ArgoCD, Tekton and Seamless Migrations

    The landscape of CI/CD frameworks has evolved over the last couple of years. From the early days of Flux and Jenkins to the current focus on ArgoCD, this journey reflects the industry’s momentum toward efficient and reliable deployments.

    In recent times, we have seen many modern software delivery platforms adopt ArgoCD or Flux for automating deployments within their ecosystems. However, as multi-cloud deployments and scalability still remain a challenge, we are seeing the industry shift toward more powerful Kubernetes-native frameworks like Tekton.

    Evolution of CI/CD Frameworks

    Flux: Paving the Way for GitOps

    Flux was one of the pioneers in promoting the GitOps methodology. It allowed developers to manage infrastructure and deployments declaratively through version-controlled manifests.

    GitOps, as introduced by Flux, emphasized the use of Git repositories as the single source of truth for configuration, making deployments more reliable and traceable.

    Jenkins: The CI/CD Workhorse

    With its extensibility and vast plugin ecosystem, Jenkins quickly became the go-to CI/CD solution for many organizations. While Jenkins was powerful, its complexity and challenges in maintaining pipelines led to the exploration of alternative solutions.

    Spinnaker: Scaling Deployments

    Spinnaker emerged as a powerful tool for continuous delivery with a focus on scalability and multi-cloud deployments.

    Its support for canary releases, blue-green deployments, and pipeline orchestration attracted organizations aiming for more sophisticated deployment strategies.

    ArgoCD: The Rise of GitOps

    ArgoCD brought a renewed focus on GitOps, building upon the foundation laid by Flux. It provided a declarative way to manage Kubernetes applications, ensuring that the desired state in the Git repository is continuously in sync with the cluster state.

    The adoption of ArgoCD has been widespread due to its simplicity, scalability and ability to synchronize with multiple clusters.

    ‘Modern’ DevOps Platforms: Riding the ArgoCD Wave

    Many ‘modern’ software delivery platforms have either incorporated or integrated separately with ArgoCD to attempt a complete software delivery approach. This integration enables users to adopt GitOps principles seamlessly within their existing workflows.

    Here’s a glimpse into what it looks like to work with ArgoCD on these platforms:

    1. First off, you will have to orchestrate CI separately, which leads to context switching and a non-unified CI/CD workflow. You will need to leverage plugins on most of these platforms and hop back and forth between exploring steps and adding them to your pipeline for a few others.
    2. For CD, it is essential for you to connect your ArgoCD instance by keying in the server URL. This requires a working understanding of ArgoCD and also a working setup of the same before even signing up to these DevOps platforms.
    3. ArgoCD has to be defined as an artifact source and its specific steps must be added as deployment steps while configuring a pipeline. Other platforms require you to include steps or commands within the YAML files to interact with ArgoCD.

    While GitOps automation can be achieved by integrating ArgoCD with DevOps platforms, it has to be noted that these are not native workflows. There will be challenges that crop up, like:

    1. Improper synchronisation between repository and the deployment state on these platforms could result in unintended deployments or configuration drift.
    2. GitOps practices, when coupled with certain platforms, may have limitations in handling multi-cloud or hybrid cloud deployments.
    3. The complexity increases with the size of the infrastructure. The larger the number of clusters and environments the greater the number of pipelines and messier the orchestration.
    4. The fact that ArgoCD needs to be set up and running before even subscribing to DevOps platforms defeats the purpose of having low-code/no-code DevOps.

    The Rise of Tekton

    As the industry looks for solutions to address the challenges posed by existing CI/CD frameworks, Tekton has emerged as a promising alternative. Prominent tech enthusiasts in the DevOps space, like CloudBees co-founder Sacha Labourey, and market momentum make it clear that there’s a significant number of organizations working on integrating Tekton within their platforms, just like we saw with ArgoCD a couple of years back.

    What’s amazing is we already had platforms like Ozone, which started working on making Tekton enterprise-ready almost three years back and have further evolved over the years.

    Tekton: Container-Native CI/CD

    Tekton is a Kubernetes-native framework for building CI/CD systems. It provides custom resources to define CI/CD pipelines as code, allowing for greater flexibility and extensibility.

    This is done by introducing the concept of tasks that run within a pipeline. These tasks are reusable and pre-defined, all of which can be viewed in the Tekton hub.

    What ArgoCD achieves for GitOps is done with just one of the hundreds of task templates that Tekton comes with.

    Too good to be true? Well, every rainbow has its rain! Migrating from one framework to another is a huge task, and that is precisely why many enterprises shy away from migration.

    Can LLMs Help Automate the Migration of Existing Pipelines to Tekton?

    If you look at the diagram below, the answer is a resounding yes. The model is trained based on existing pipelines and what their corresponding Tekton pipelines look like.

    The overarching objective of this workflow is to facilitate a seamless conversion process using large language models (LLM) for generative AI.

    Central to this approach is using the chat context and the strategic application of roles for LLM models to establish context. Additionally, sample pipelines are leveraged to train and fine-tune the model to define how the corresponding YAML files of all these platforms look for any given pipeline.

    Here’s a more detailed read presented by Ozone as an industry-first last year at KubeCon North America.

    Conclusion

    The evolution of CI/CD frameworks reflects the DevOps industry’s dynamic nature and the demand for efficient software delivery pipelines. From Flux and Jenkins to ArgoCD and Tekton, each framework addresses deployment challenges.

    ArgoCD gained traction based on its GitOps principles and Kubernetes integration, yet faces synchronization, multi-cloud support and scalability hurdles. Tekton, a Kubernetes-native CI/CD framework, offers scalability, event-driven architecture and cloud-native practices to make up for these shortcomings.

    Whether embracing ArgoCD or exploring Tekton, the goal is resilient, scalable pipelines driving innovation and time-to-market acceleration.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation, Techstrong Group and the entire cloud-native community in Paris, France at KubeCon+CloudNativeCon EU 2024 – March 19-22, 2024.