Tag: continuous delivery

  • CD Foundation Touts Spinnaker CD Progress

    CD Foundation Touts Spinnaker CD Progress

    At an online Spinnaker Live event today, the Continuous Delivery (CD) Foundation revealed the open source CD platform is gaining significant momentum since being contributed by Netflix late last year.

    There were on average 842 merged pull Spinnaker requests a month in the first quarter of 2020. A total of 1,183 contributors participated in the project in the last year, with 40% of those contributors participating in the first quarter. Since the first quarter, the project has added at least two new contributors a week.

    Rosalind Benoit, chair of the CD Foundation Outreach Committee and director of community at Armory, a provider of an enterprise edition of Spinnaker, said the bulk of the increased contributions to Spinnaker are coming from Amazon Web Services (AWS), which the cloud service provider is already employing to orchestrate software delivery across multiple platforms.

    Benoit said Spinnaker represents an effort to finally address CD issues that have been difficult for most organizations to solve. While continuous integration (CI) is a solved problem, Benoit says CD remains problematic. Each platform code is deployed on within enterprise IT environments is a snowflake; as such, not much progress has been made toward automating the delivery of code across different platforms, said Benoit.

    The goal for Spinnaker is to create a foundation for CD that will achieve groundswell support that was achieved for Kubernetes by the Cloud Native Computing Foundation (CNCF), she noted. Both the CD Foundation and CNCF are arms of the Linux Foundation.

    Last year, the CD Foundation was launched to advance development and adoption of Spinnaker alongside Jenkins, an open source CI/CD platform; Jenkins X, an opinionated open source CI/CD platform for Kubernetes; and Tekton, an open source project and specification for creating CI/CD components.

    While many DevOps teams have attempted to address CD challenges using Jenkins, progress has been uneven at best. Spinnaker was built by Netflix specifically to automate software delivery across multiple clouds using a framework that can be integrated with any CI tool. As such, it serves to provide a clearer line between where CI ends and CD begins.

    Historically, most application code is pushed from a CI tool out to a deployment platform. As Spinnaker and other cloud-native platforms such as Kubernetes continue to evolve, the process of pulling images from CI tools to achieve CD goals will become much more automated.

    It’s not clear just how much depth of support for Spinnaker there is among providers of DevOps platforms. Members of the CD Foundation in addition to Armory include CloudBees, CircleCI, Google, Huawei, IBM, JFrog, Netflix, GitLab, Harness, Puppet, Rancher Labs, Red Hat, SAP and Sysdig. AWS has yet to formally join the CD Foundation. However, few of these vendors have detailed how they intend to incorporate Spinnaker in their respective platforms.

    In the meantime, DevOps teams should be paying close attention to how best CD practices will evolve alongside existing CI processes because it’s clear the next major phase of their continuing DevOps adventure is only now just beginning.

  • Harness Enables DevOps Teams to Rein in Cloud Costs

    Harness Enables DevOps Teams to Rein in Cloud Costs

    Harness today unfurled its Continuous Efficiency application, which enables DevOps teams employing its continuous delivery platform delivered as a service to monitor the cost of deploying applications on a public cloud.

    Company CEO Jyoti Bansal said cloud costs are spiraling out of control within many IT organizations because DevOps teams lack visibility into the true cost of deploying an application on not just one cloud versus another but also specific tiers of services made available by cloud service providers.

    Continuous Efficiency provides DevOps teams with granular cost breakdowns by cloud provider, cloud service, application, microservice and environment, as well as by Kubernetes cluster, namespace, workload, node and pod.

    Bansal said that capability is crucial for organizations looking to identify underutilized resources that they today typically only become aware of when a monthly bill is presented by the cloud service provider. Even then, it’s too late for the DevOps teams to proactively optimize the cloud environment to minimize costs.

    In fact, it’s currently too difficult to correlate the monthly bill presented by a cloud service provider with specific application services that might have been consuming that infrastructure, he noted, adding Continuous Efficiency is specifically designed for DevOps teams rather than the finance team.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, DevOps teams are under more pressure than ever to reduce cloud costs, said Bansal. Not only has the cloud become the single largest expense for DevOps teams, but also IT leaders are being required to better predict costs at a time when organizations are unsure how much revenue they are able to generate from one month to next. The days when DevOps teams could view the cloud as essentially a free resource are now over, he noted.

    Beta customers who tested Continuous Efficiency have been able to realize as much as $500,000 in annualized savings on their cloud costs, Bansal added.

    Harness is leveraging its continuous delivery service to auto-discover cloud costs without requiring IT teams to manually tag cloud resources. As a CD platform accessed as a service, Harness is able to aggregate all that data in real-time on behalf of its customers. The Harness platform supports Amazon Web Service (AWS), Microsoft Azure and Google Cloud Platform, including the Kubernetes based services provided by those services.

    Much like the rest of the IT environment, Bansal said responsibility for managing cloud costs will increasingly shift left toward DevOps teams. As one of the primary consumers of those services, it’s typically DevOps teams who have the most variable consumption of cloud services. All too often, it turns out that costs are being incurred because developers have reserved instances of virtual machines on a public cloud for sake of convenience but are not actually using. When many organizations are deeply concerned about cash flow, tolerance for that behavior is quickly dropping to near zero.

    Rightsizing of cloud computing environments has, of course, been inevitable. The thing that has changed is the current economic climate has transformed rightsizing from being merely the desired goal into an absolute requirement.

  • DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    DevSecOps vs. Agile Development: Putting Security at the Heart of Program Development

    Despite most developers and managers being well aware of the concept of DevSecOps, it is still often confused with a number of related processes and concepts. This is particularly true for the Department of Defense (DoD) contractors because they have long been encouraged to use a related process known as agile development. 

    Since agile development has been around for more than a decade, there is a tendency for organizations to regard DevSecOps as an extension, or even a synonym, for it. In reality, though, the two approaches are distinct. The objectives of both approaches are similar: balancing speed and agility, detecting risk early and both focus on cloud-native security and performance. 

    However, while DevSecOps does build on some agile development principles, such as the continuous integration and delivery of software systems in cycles, its key emphasis from the beginning of the process is to integrate security features, while Agile only focuses on delivering software.

    In this article, we’ll look at the key differences between agile development and genuine DevSecOps processes, and how each complements the other.

     

    DevSecOps vs. Agile Development

     

    The difference between DevSecOps and agile development methodologies can be understood in reference to one aspect of software development: security. When, where and who implements security in software development varies between the two approaches.

    Agile development methodologies focus on iterative development cycles, in which feedback is continuously reintegrated into ongoing software development. However, even in mature agile development processes, security is still often added to software as an afterthought. This should not be read as blaming software developers for often underestimating the potential harm from malware or overlooking the importance of cybersecurity. 

    Rather, in many firms, it is simply not the responsibility of developers to think about the security implications of their code, because software will be passed to the security team before release.

    DevSecOps takes security and puts it on the same level as continuous integration and delivery. DevSecOps methodologies emphasize security at the very earliest stages of development and make security an important part of overall software quality.

    In essence, these approaches shift the program manager’s perspective away from making sure that software is in compliance or meets a specification or audit, to ensuring that the code is written correctly and securely and that it’s deployed in a repeatable manner.

     

    The Changing Culture of the DoD

     

    The adoption of DevSecOps methodologies is critical for DoD contractors because these methodologies reflect DoD’s own modernization strategy. Following high-profile vulnerabilities being discovered in all types of systems, DoD seems to have released that cybersecurity weaknesses are not just a potential threat to critical defense data, but also impose a significant operational bottleneck on the continuous delivery of functionality.

    At the moment, even those firms who possess a mature agile development framework can find that the multiple security checks and compliance processes that must be performed on software, prior to shipping, can detrimentally impact on their ability to deliver iterative software improvements. This is the issue that the transition to DevSecOps seeks to overcome, by attempting to shift organizations’ approach to cybersecurity away from compliance, and toward genuine security consciousness.

    At the same time, analysts are aware that shifting responsibility for cybersecurity onto developers will be uncomfortable, and potentially dangerous, for many DoD contractors. Developers working on the base code for military software do not have – and are not expected to have – an exhaustive appreciation of all of the contexts in which this will be deployed, and exactly which systems their software will be required to interface with.

     

    Automation and New Models

     

    In response to these concerns, DoD contractors are reappraising the DevSecOps model and thinking seriously about how it can be deployed in contexts where continuous service delivery is key. There are three key ways in which this is happening.

    The first is the rise of automation. The types of large-scale, multicloud infrastructures that most contemporary DoD projects rely on can often necessitate repetitive, ongoing maintenance and security assessment across both development and security teams. DevSecOps replaces these human checks with automated systems: Instead of requiring a person to go through checklists of hundreds of controls, this is done automatically as part of the software development and supply process pipeline. 

    The second key element in the transition to DevSecOps is endpoint security. The types of monolithic development processes that DoD contractors traditionally worked with are not suited to the contemporary deployment environment of many DoD projects. In these traditional methods, systems were built as discrete holes, with no expectation that data would be exposed as it moved between components. 

    This is now an obsolete approach: In DevSecOps processes, virtual private networks are used to provide security and encrypt data as it moves within a network, and the principle of least privilege reduces staff access to small portions of It environments. 

    Thirdly, a new generation of younger military and civilian personnel in the DoD, many of them trained in the commercial sector rather than entering the military directly from college, are bringing corporate approaches to the development of military software. This is seen in the exponential increase in the utilization of cloud services in DoD applications, and more dynamic and distributed managerial frameworks that distribute security responsibility across entire organizations, rather than having this as the sole remit of a dedicated security team.

     

    Get Support

     

    Moving to a truly DevSecOps methodology is likely to be a challenge for many contractors. However, just as in the last decade many firms have had to redesign their development lifecycles in order to be agile, now they will need to achieve secure development lifecycles in order to stay competitive.

    If you are looking to make this shift, you should also recognize that you are not alone. DoD is working actively with its partners in order to facilitate the roll-out of DevSecOps processes and to make commercial tools and techniques available and useful for military contractors because the department recognizes the value of this methodology for the software they commission. 

    This is seen most clearly in the recent updates to Microsoft Azure Government, though you should also be aware that many of the resources recently released by the Defense Logistics Agency are also focused on the transition to DevSecOps.

    In short, whilst the transition to DevSecOps may be challenging, it will be no more so than the earlier shift to agile development. To make this shift, however, firms should draw on the resources available to them, recognize the value of integrating security into their development workflows and build on existing agile frameworks.

  • CircleCI Extends Core CI/CD Platform

    CircleCI Extends Core CI/CD Platform

    CircleCI today in partnership with Plandek launched an analytics plugin dubbed Buildtrakr for its namesake continuous integration and continuous delivery (CI/CD) platform. Buildtrakr integrates with CircleCI and Git to synthesize commit and build performance data, with critical metrics being surfaced via a dashboard.

    In addition, CircleCI has revamped its user interface and reconfigured a new fleet of Docker images, also known as CircleCI convenience images, to optimize them for a continuous integration environment.

    CircleCI CEO Jim Rose said Docker images made available by CircleCI are faster, easier to download and provide a more efficient way to build custom images. CircleCI also released a new category of convenience images available for languages such as Python, Ruby, Rust, Go and several others, that come with improved documentation, more stability and more efficient infrastructure. Those convenience images are individual open source projects and can be used in IT environments other than the CI/CD platform from CircleCI.

    Finally, the company also announced that its insights endpoints now offer start and end date parameters for workflows and jobs. These parameters restrict the range of executions returned based on their start times in addition to providing a new filter to use for testing analysis.

    Rose said the new user interface is significant because it makes it possible to view the status of entire pipelines more easily while making it easier for more advanced DevOps teams to leverage workflows.

    The redesigned interface also adds a filterable view with nested workflow and job information, making it easier to scan the status of recent builds. Pages were also overhauled to deliver more digestible job details, full-screen step outputs for easier debugging and a cleaner configuration-as-code view. There’s also been a 65% reduction in page load times, noted Rose.

    In general, Rose said activity on the CircleCI platforms in cloud environments is on the rise in the wake of the COVID-19 pandemic. Organizations that are working remotely due to stay-at-home directives and can’t access a local data center have come to realize that having a build box located under someone’s desk is no longer a viable option.

    Of course, it remains to be seen how much of that initial burst of activity will result in new applications being deployed. However, with more organizations starting to build and deploy digital business applications to engage customers, it may be only a question of when IT operations teams will be able to catch up to a building backlog of applications. In fact, many of those applications are now likely to be deployed on the same cloud where they were constructed.

    Whatever the path forward, there most certainly will be a greater reliance on metrics. Naturally, the hope is that analytics will be used to coach DevOps teams to become more efficient versus simply riding roughshod over developers. After all, the goal isn’t to write more code faster but to deliver better code at the right time.

  • CloudBees Connect Virtual Summit: Defining the Future of Software Development

    CloudBees Connect Virtual Summit: Defining the Future of Software Development

    CloudBees Connect Virtual Summit will bring together a global community of developers, CloudBees and Jenkins users, DevOps luminaries and continuous delivery experts for two full days of immersive learning, presented in a virtual reality environment. The event is scheduled to take place on May 19 at 11 a.m. EDT for North America, and on May 20 at 11 a.m. CET for the European audience.

    At CloudBees Connect, you will learn about the emerging trends and technologies shaping the future of software, including one of the most innovative trends in technology: continuous delivery. Continuous delivery allows you to deliver software faster and with lower risk, while preserving quality and reliability.

    Industry leaders will share their knowledge and expertise on CI/CD tools and best practices. You will learn how to successfully create a fully operational CD pipeline using containers, Kubernetes and Jenkins X; and how to automate security and privacy testing in your Jenkins CI/CD pipeline for continuous security.

    The event will consist of a series of workshops designed to provide great value to the attendees. Here are a few things you will learn by attending these workshops:

    • How your COBOL source code can be branched/merged/deployed using GitHub, CloudBees and Compuware tooling.
    • Best practices for continuously integrating code using CloudBees Core.
    • How to build and test applications using Jenkins Pipelines and Sauce Labs.
    • Solutions for the five most common Jenkins issues.
    • The role of feature flags in reducing risks associated with deployments.

    The workshops will feature a lineup of DevOps and continuous delivery leaders, including:

    • Oscar Medina, developer advocate at CloudBees
    • Viktor Farcic, Jenkins X product manager, principal software delivery strategist and developer advocate at CloudBees
    • Josh Grant, solution architect at Sauce Labs
    • Robert Kelley, director of delivery engineering at IHG
    • Stuart Ashby, DevOps specialist at Compuware
    • Alex Taylor, DevOps engineer at insightsoftware

    Discover what’s next from the CloudBees and Jenkins community, connect with industry experts and fellow developers, and get the skills and hands-on training you need in order to successfully deliver software.

    To check out the agenda, the full lineup of speakers and to register (for free), visit the CloudBees Connect website.

  • Report Finds Much Room for CD Improvement

    Report Finds Much Room for CD Improvement

    A report published by Harness, a provider of continuous delivery (CD) platform accessed via the cloud, finds organizations are spending on average $109,0000 per year just to deploy per application.

    Based on a survey of more than 100 organizations, the report finds organizations are struggling with deployment frequency, lead time and meantime to recover after a failed release.

    On average, organizations are deploying code to production every four days, which takes about eight hours to complete, according to the report. An average of 11% of those deployments fail and those failures take an average of 60 minutes to manually roll back.

    Steve Burton, CMO at Harness, said that while a lot of progress has been made in recent years in terms of implementing continuous integration (CI), the continuous delivery (CD) side of the DevOps equation remains challenging. Each platform an application gets deployed on is a unique “snowflake” that requires organizations to rely on custom scripts to deploy an application. The report finds deployment pipelines are expensive to create and maintain, requiring two to three dedicated full-time employees and up to 66 hours to onboard a new application. New artifacts on average took 5.5 hours to reach production and then 10 hours per deployment.

    Harness has been making a case for a dedicated CD platform that is accessed as a software-as-a-service (SaaS) platform. That approach provides a way to automate application delivery in a way that more easily complements the variety of tools and platforms organizations rely on to build applications, he said.

    The Harness report finds 71% of respondents employ the Jenkins CI/CD platform. Other popular tools and platforms include Jira project management software (76%), Selenium for testing (63%) and Amazon Web Services (AWS) for cloud deployment (65%). While Jenkins can be employed to deliver applications, Burton said the survey results make it clear there’s not been a lot of progress when it comes to CD.

    It’s too early to say to what degree changing economic conditions brought on by the COVID-19 pandemic might encourage IT organizations to rethink their approach to DevOps. Organizations are undoubtedly going to be more sensitive to cost. Much of the cost involved in DevOps comes from first standing up and maintaining the DevOps environment and then hiring IT professionals with DevOps skills to manage it. A SaaS platform, in contrast, is maintained by the provider, comes with built-in analytics tools, enables automatic rollbacks and is paid for on a consumption basis, notes Burton.

    No one knows for sure at what rate organizations might be rolling out new applications in the months ahead. While some may choose to pull back, others are advancing various digital business initiatives as part of an effort to become more resilient. In many cases, that means replacing many legacy applications with fewer modern applications that run natively in the cloud.
    Regardless of the path forward, the one thing that is certain is the level of scrutiny being applied to DevOps efficiency is about to substantially increase.

  • How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    Since Jez Humble and David Farley popularized the term in 2010, continuous delivery has revolutionized software delivery practices. 

    Creating mature continuous integration/continuous delivery (CI/CD) pipelines has helped enterprises deliver software that performs better, based on a long list of metrics. Failure rates have dropped from 50% to under 15%, and cycle times are measured in hours, not weeks. Organizations get to market faster and release products into production with fewer bugs.

    But, there’s a limit to what CI/CD can provide. CI/CD connects only the parts of the software lifecycle that happen inside DevOps. It doesn’t provide insights into where the delivery cycle is breaking down, whether the software is helping the business meet its internal key performance indicators (KPIs), how customers are responding to it or whether last week’s release is achieving the internal efficiencies the business was projecting.

    A More Holistic Approach

    This is where a more holistic approach to software delivery can help. As we discussed in a previous blog, there’s a move afoot to recognize software delivery as more of a core business process and connect all the aspects of this process in one new, interconnected discipline. 

    The new discipline, called software delivery management (SDM), changes the game by going beyond CI/CD and empowering developers and other stakeholders to best collaborate and creatively solve problems. It gives them the data, insights and best practices that allow them to truly continuously improve, keep value flowing and efficiently develop and deliver the right products and features to customers.

    To follow SDM principles, a management solution needs to rest upon four key pillars: common data, universal insights, common connected processes and having all functions collaborating.

    • Data: All information within and around software delivery activity would need to be captured and stored with a consistent domain model to enable and facilitate connected processes, shared insights and collaboration.
    • Insights: Visibility and insights would need to enable a common understanding and continuous learning from data across, up-and-down and throughout all functions in the organization.
    • Processes: Processes would need to orchestrate the entirety of the software delivery value stream and connect functions together to efficiently bring ideas to market with maximum value and adoption.
    • Collaboration: All functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.

    This holistic approach helps organizations in a number of ways. Here are three benefits DevOps managers can net in terms of the way they work, collaborate with development teams and connect with peers throughout their organizations.

    Faster Development

    The current process can be slow and tedious. Developers use tools configured to perform one task, and getting a complete end-to-end view across the toolchain is difficult. An SDM solution stores all the artifacts and data from disparate tools that move software from idea to deployment in a unified common data layer. The information is connected and available for those who need it, when they need it and in a form they can use. Just forging these connections will save hours of time looking for data, checking statuses and tracking issues throughout the delivery process. 

    Better Software

    If stakeholders have no end-to-end view of the development and delivery process, they have no way of knowing if the software is meeting the organization’s business objectives. With SDM, the continuous feedback loop established with CI/CD and DevOps is extended to fully include all stakeholders from the ideation phase through user adoption and back to ideation. Better insights are tracked more closely and shared more widely, helping developers do a better job of delivering what the users want.

    Better Collaboration

    Developers and business leaders don’t collaborate well for a number of reasons. Developers often don’t have a good feel for how a product is going to be used, and business leaders usually don’t have insight into what’s in development or when it will be delivered. This is complicated by scattershot communications processes–where both sides have to sort through spreadsheets, connect over email threads and wait for meetings to move processes forward. With SDM, the silos between the software organization and other stakeholders are broken down, so both sides can share information, communicate more directly and drive toward solutions. 

    In an upcoming blog, we’ll explore other examples of SDM in action and dive into the business value it creates for organizations.

  • Stay Ahead of the 5G and DevOps Race with Continuous Network Monitoring

    Stay Ahead of the 5G and DevOps Race with Continuous Network Monitoring

    All car owners are aware that they should have their car regularly serviced. This includes routine maintenance checks, as well as expert assessments for potential future problems. Whether you like it or not, it’s important to pay attention and listen to your mechanic’s warning–it could be as simple as your tire treads, or abnormal wear and tear that could bring back worse issues if not fixed in the foreseeable future.

    Automobiles aside, another industry that benefits from being proactive rather than reactive is telecommunications. Not only does the telecoms world requires routine checks and maintenance, but it also needs to identify problems before they cause larger issues or disruptions.

    Networks are evolving rapidly and this will continue as 5G deployments expand; as will the need for regularly scheduled maintenance and examinations. DevOps–a set of procedures that automates between software development (Dev) and IT operations (Ops) along with continuous delivery (CD)–allows for a level of agility that enables new features and services to be deployed within weeks or days. There are four stages of establishing these services–design, deploy, test and operate–all of which demand a constant pace and network monitoring.

    To maximize DevOps and CD, including the speed benefits that come with both, predictive network monitoring (PNM) is vital. 

    Powering Networks with Prediction Services

    PNM services predict abnormalities within a network and their subsequent implications, isolate affected areas, examine outcomes and recommend actions. PNM also utilizes continuous monitoring functions; leverages real-time data to address issues before they affect the business; and provides continuous verification in near real-time in order to offer a holistic performance overview of all levels of a telecommunication ecosystem.

    PNM has the potential to reduce the number of occurrences affecting networks by nearly 40%; to reduce restore time by 48%; and to reduce faults per subscriber by 85%. When you put this all together, PNM can then improve the time between failures by 64%, and when you use artificial intelligence (AI) and machine learning (ML), even better numbers can be achieved. This is because AI and ML can monitor network data in a closed-loop system, enabling the automatic detection of anomalous behavior and system abnormalities.

    While a majority of cars lack these types of PNM services, telecom networks are already ahead of the game with their increased ability to predict issues and intervene before they can adversely affect the business, thus saving time, money and effort for operators.

  • CD Foundation Serves Up Tekton Pipelines Beta

    CD Foundation Serves Up Tekton Pipelines Beta

    The team overseeing the development of the open source Tekton Pipelines under the auspices of the Continuous Delivery (CD) Foundation announced today the project is now in beta.

    Christie Wilson, Tekton Project Lead and a software engineer at Google, said Tekton Pipelines are not necessarily a tool most DevOps teams will interact with directly. Rather they provide a foundation on which DevOps platforms can be built that will make it easier for DevOps teams to construct workflows spanning multiple continuous integration/continuous delivery (CI/CD) platforms.

    As such, Tekton Pipelines should play a critical role in not just fostering interoperability but also alleviating concerns about become locked into a specific CI/CD platform.

    The beta release of Tekton Pipelines is significant because it signals that the project is now stable enough to be incorporated in DevOps platforms and from here on will follow the same deprecation policies as Kubernetes in terms of supporting previous releases. However, Wilson noted that Tekton Triggers, Tekton Dashboard, Tekton Pipelines CLI and other components are still alpha and as such may evolve from release to release in a way that is not necessarily backward-compatible just yet.

    In the meantime, the Tekton Pipeline team is encouraging all Tekton projects and users to migrate their integrations to the latest version of Custom Resource Definition (CRD), which is the application programming interface (API) supplied. The Tekton Pipeline team is also making available a migration guide.

    The Tekton Pipelines project is one of several initiatives being advanced under the guidance of the CD Foundation, which is an arm of The Linux Foundation. Other projects include Jenkins and Jenkins X, a pair of open source CI/CD projects developed originally by CloudBees and Spinnaker, a CD platform originally created by Netflix. Tekton Pipelines are a framework that runs natively on Kubernetes that traces its lineage back to Google.

    Premier members for the CD Foundation include CloudBees, Google, Circle CI, JFrog, IBM, CapitalOne, Salesforce and Netflix. Other members of the CD Foundation include GitLab, Red Hat, Harness and Rancher Labs.

    Wilson said Jenkins X already supports Tekton Pipelines, while work involving Spinnaker is ongoing. It’s not expected that Jenkins, currently the most widely used CI/CD platform, will be able to employ Tekton Pipelines, said Wilson.

    It’s not clear when Tekton Pipelines might be pervasively employed across multiple CI/CD platforms. In theory, as more applications are built on top of Kubernetes, the use of CI/CD platforms that run natively on Kubernetes should increase. However, most organizations that have already adopted a CI/CD platform such as Jenkins are continuing to use the same platform to build and deploy both monolithic and microservices-based applications. At some point, however, it’s expected those organizations will eventually migrate to a CI/CD platform that runs natively on Kubernetes. In many cases, different teams within the same organization may opt to standardize on different CI/CD platforms while still be able to share workflows, said Wilson.

    Naturally, providers of DevOps platforms are already jockeying for position now that the race to support Tekton Pipelines as specified by the CD Foundation has formally started.

    — Mike Vizard

  • GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab this week announced it has moved 18 features that previously organizations had to pay for into the core open source version of its namesake continuous integration/continuous delivery (CI/CD) platform.

    Scott Williamson, executive vice president of product management for GitLab, said as a general rule the company makes available DevOps tools for teams across the four tiers of services that organizations can employ. Features now being migrated to the Core offering include:

    Plan: Synchronize collaboration with “related issues,” “export issues,” “issues board focus mode” and “Service Desk”

    Create: Build better code and branch with the “web terminal for WebIDE,” “file syncing to web terminal” and “design management”

    Verify: Improve code quality with reports on merge requests

    Package: Build and share more efficiently with a set of package managers in one place

    Release: Continuous delivery simplified with “canary deployments,” “incremental rollout,” “feature flags” and “deploy boards”

    Configure: Support for multiple Kubernetes clusters to ease deployment of different environments

    Defend: Bolster application security with network policies for container network security

    As the global economy falters in the wake of the COVID-19 pandemic, it’s likely reliance on open source software will increase. Most organizations would rather throw IT labor at the ongoing management of an IT environment to manage open source software versus having to lay off IT employees that would be extremely difficult to find once the economy recovers. It remains to be seen to what degree that strategy will play out in DevOps environments, but Williamson said historically most of GitLab’s customers are organizations that first adopt the open source version of its platform.

    Less clear is the degree to which the downturn might also induce many of the organizations to employ a DevOps platform delivered as a set of software-as-a-service (SaaS) applications. GitLab has been for the past several years for an integrated approach to DevOps based on a single code base that is ultimately easier to deploy and manage. Many IT organizations may decide that rather than manage DevOps infrastructure, they now prefer to allocate what limited resources they have on hand to writing code.

    The number of application development projects being launched could also decline while others are suspended. At the same time, however, there are some vertical industry segments, such as digital entertainment and education services, that might see a spike in demand for additional services now that many people are staying home to help limit the scope of the COVID-19 pandemic.

    Of course, many DevOps teams are among the legions of workers that now need to remotely access platforms. Williamson said supporting remote DevOps teams has long been a strength of the GitLab platform. GitLab also makes available a playbook that provides DevOps teams with guidance on how best to work remotely.

    Clearly, it will be a few months before the full impact of the COVID-19 pandemic is fully appreciated. Regardless, many IT organizations are clearly preparing for the worst of times while continuing to hope for the best outcome possible.

    — Mike Vizard