Tag: Jenkins

  • A Data-Driven Approach to DevOps: Tips for Improving Speed and Scale

    A Data-Driven Approach to DevOps: Tips for Improving Speed and Scale

    Data has an undeniable power in a business context — it can sway stakeholders, help identify pain points, and demonstrate how changes are making an impact on the company. As the creator of Jenkins, Kohsuke Kawaguchi has noticed from his conversations with business leaders in the industry that implementing a data-driven mindset can be a game changer in the DevOps journey. 

    While data may not initially seem like it provides a full enough picture for businesses to work with, it carries invaluable insights and a certain level of objectivity that allows for a smoother transition in the DevOps process. Additionally, adopting a data-driven approach helps to showcase the small wins in your DevOps journey that can help build more confidence and trust in the process. 

    In the interview below, Kohsuke teases his session, “Go Data Driven With Your DevOps: 5 Tips for Improving Speed and Scale,” at TechStrong Con.  On July 15, Kohsuke, along with fellow Launchable Co-Founder Harpreet Singh, will provide tips on how a data-driven approach to DevOps can help improve speed and scale. 

    To see the full agenda and secure your free spot at the virtual event, visit the TechStrong Con website.

  • CDF Officially Graduates Jenkins CI/CD Platform

    CDF Officially Graduates Jenkins CI/CD Platform

    The Continuous Delivery Foundation (CDF) announced today that the open source Jenkins continuous integration/continuous delivery (CI/CD) has officially graduated.

    Jenkins was donated last year to the CDF, an arm of The Linux Foundation, along with Jenkins X, a CI/CD platform for Kubernetes; Spinnaker, a CD platform; and Tekton, a framework for building pipelines that will be employed as the foundation for next-generation CI/CD platforms.

    Tracy Miranda, CDF Governing Board Chair and director of open source community at CloudBees, said that although Jenkins traces its lineage back to 2004, the CDF wanted to make sure the same requirements that are being applied to graduate other projects are applied to Jenkins despite its obvious maturity. The CDF requirements for graduating a project are to demonstrate growing adoption, have an open governance process, feature maturity and a strong commitment to community, sustainability and inclusivity.

    The CDF also today published a public road map for Jenkins. Key features include improving the user/administrator experience and tighter integration with cloud platforms. Work has also begun on Operator tools for simplifying the deployment of Jenkins on a Kubernetes cluster.

    Longer-term, the CDF is focused on expanding the adoption of Tekton-based Trigger pipelines across both Jenkins and Spinnaker. Tekton pipelines are easier to create and can be reused across multiple platforms. Jenkins X already employs Tekton-based pipelines, which were originally developed by Google.

    The founding members of the CDF are CloudBees, Google, CapitalOne, CircleCI. Fujitsu, Huawei, IBM, JFrog, Netflix and Salesforce.

    In the nearer term, Miranda said the CDF is also attempting to standardize the glossary of terms applied to DevOps processes. The goal is to provide something akin to a “Rosetta Stone” that will help make DevOps more accessible to IT professionals just starting their journey.

    In theory, at least, platforms such as Jenkins X accelerate the development of microservices-based applications running on Kubernetes clusters. In practice, however, many IT teams continue to use Jenkins and other CI/CD platforms to build both monolithic and microservices-based applications.

    As Kubernetes gains momentum, however, the way applications are deployed may also evolve. Today most DevOps teams push application code from a CI/CD platform on to a target system. However, if Kubernetes is deployed on multiple platforms it may become easier to automate the delivery of code by enabling Kubernetes clusters to pull code from CI/CD platforms on demand.

    As organizations transition to building and deploying microservices-based applications, it’s also apparent there will be a much greater need to rely on best DevOps practices to manage all the dependencies that will exist between each microservice. Legacy application development processes will not be able to keep pace with the rate at which microservices based on containers are ripped and replaced.

    Of course, it’s not clear to what degree organizations may prefer to stay with Jenkins, which is built on a Java virtual machine, versus adopting Jenkins X or a CD platform such as Spinnaker. However, as the interoperability between these platforms continues to improve, it may not be surprising to one day find DevOps teams employing a mix of all of them across different application development projects.

  • The Linux Foundation Adds Free Jenkins Training Course

    The Linux Foundation Adds Free Jenkins Training Course

    The Linux Foundation, in collaboration with the Continuous Delivery Foundation (CDF), today launched a free introductory course to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform as part of what it plans will become a series of free and paid online DevOps tools courses.

    Clyde Seepersad, general manager of training at the Linux Foundation, said that while the foundation already provides access to some higher-level conceptual DevOps courses, the launch of the CDF last year provides a knowledge base from which the Linux Foundation can now provide online courses specific to DevOps tools. The CDF is an arm of The Linux Foundation.

    The Linux Foundation will also provide courses on Spinnaker, a CD platform, and other DevOps tools that, along with Jenkins, are now being developed under the auspices of the CDF, he added.

    In general, Seepersad said demand for DevOps expertise is increasing as organizations more aggressively embrace digital business transformation initiatives in the wake of the COVID-19 pandemic. At the same time, IT teams are adopting a wider range of cloud-native technologies to build more flexible and resilient applications. DevOps platforms such as Jenkins make it possible for IT teams to build those applications faster.

    The challenge many organizations underestimate is the extent of changes to their internal IT culture required to make that transition, Seepersad said—too many organizations still put tools into the hands of developers without really thinking through the workflow issues between developers and IT operations teams.

    The most important thing for any organization to do, he said, is to make sure there is an open DevOps dialogue versus tiptoeing around issues that will tend to increase resistance only further.

    Ultimately, free training should help expand the overall size of the DevOps community at a time when many IT professionals are trying to increase their skills. DevOps professionals not only command higher salaries, but they are also less likely to be laid off. DevOps teams oversee the development and deployment of applications and can also programmatically manage levels of infrastructure that IT administrators relying on traditional graphical user interface (GUI) tools can’t match. That’s a critical issue when many IT organizations these days are trying to do a lot more with even less.

    There’s nothing quite like an economic crisis to focus everyone’s mind. The biggest DevOps challenge any organization typically faces is overcoming inertia. Too many IT professionals have relatively narrow skillsets that conspire to increase the total size of the IT organization. In addition to relying on increased levels of automation to reduce costs, IT leaders want to be able to scale IT environments without having to increase headcount.

    It may take a little while longer for the transition to DevOps to fully play out. However, it’s now more of a question of existential survival rather than if or even to what degree to embrace DevOps. Organizations that don’t embrace DevOps processes to ruthlessly automate the management of IT now might very well never get another chance.

  • 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.

  • Google Names CloudBees App Dev Partner of the Year

    Google Names CloudBees App Dev Partner of the Year

    Google this week named CloudBees its 2019 Cloud Technology Partner of the Year for Application Development at a time when the rate at which application workloads are heading into the cloud is expected to accelerate.

    Beyond the Jenkins continuous integration/continuous delivery (CI/CD) platform on the Google Cloud Platform (GCP), CloudBees also makes available a software-as-a-service (SaaS) edition of Jenkins X, a CI/CD platform optimized for Kubernetes, along with a CloudBees Software Delivery Management (SDM) service for managing DevOps processes.

    François Dechery, chief strategy officer for CloudBees, said CloudBees chose to partner with Google at that level versus other cloud service providers because Google made it clear it would partner at both the technology and business development level. In addition, given Google’s long history with Kubernetes, it also made sense to leverage existing Kubernetes expertise, he noted.

    In the wake of the COVID-19 pandemic, more application development work will be moving onto cloud platforms that can be remotely accessed more easily by development teams, he added.

    In some cases, organizations will opt to self-manage those platforms or rely on a traditional managed service provided by a third-party IT services firm. However, Dechery said there also has been a significant increase in the number of organizations willing to consume a DevOps platform such as Jenkins X as a SaaS application, as long as the IT environment is proven secure. SaaS platforms are now a mainstream element of any enterprise IT environment, said Dechery.

    Many of those decisions will be predicated on what degree of abstraction any organization is comfortable with as IT platforms become both more complicated and diverse, added Dechery, noting one thing that attracts organizations to Jenkins X is that it abstracts away the complexity associated with deploying Kubernetes. The Kubernetes deployment process is automated by Jenkins X, which essentially provides a level of abstraction on top of another abstraction.

    Dechery conceded there is some level of inherent competition with cloud service providers that provide their own DevOps tools. However, most of those DevOps platforms are not up to the task of building and deploying applications at scale, he said. In addition, platforms such as Jenkins and Jenkins X make it feasible to manage application development projects at scale without having to worry about becoming locked into a single cloud service provider, he added.

    Competition across the CI/CD platform space remains fierce. CloudBees has long benefited from a large open source Jenkins community that often leads to organizations implementing an enterprise edition of Jenkins supported by CloudBees. However, as organizations embrace microservices-based applications based on containers, many of them are revisiting their platform options. That doesn’t necessarily mean they will rip and replace existing investments in Jenkins platforms; however, given the rate and scale at which modern applications are being built and delivered today, many organizations may be moving toward more prescriptive approaches to bring some order to the chaos.

    — Mike Vizard

  • DevOps Chats: CloudBees Remains at Top of DevOps Market

    DevOps Chats: CloudBees Remains at Top of DevOps Market

    In this special DevOps Chats video edition, we speak with Sacha Labourey, CEO of CloudBees. From the very beginning of the DevOps movement, CloudBees has been one of the companies at the top of the DevOps market and, based on its latest business metrics, the company remains there.

    Being the enterprise Jenkins company helped CloudBees early on to be a leader at the top of the DevOps market. But with Jenkins and Jenkins X handed over to the Continuous Delivery Foundation (CDF), CloudBees can no longer count on its Jenkins connection to stay on top.

    Sacha, like any good CEO, did not allow CloudBees to rest on its laurels. An aggressive acquisition strategy including acquiring Electric Cloud, Rollout.io and others, has kept CloudBees on top. At the same time, Sacha has led the product and engineering teams as they roll out a new generation of DevOps products and services including the upcoming Software Delivery Management (SDM) and Software Delivery Automation (SDA).

    In this video, Labourey lays out what the past year has seen for CloudBees and what the coming year could bring. Of course, with Covid19 everyone is sailing into unchartered waters. But Sacha has the course in mind for CloudBees to follow.

    Have a listen to our conversation with Sacha to understand CloudBees’ plan to stay at the top of the DevOps market.

    [video src="https://videos.files.wordpress.com/TNgFIQ9x/2020-03-19-interview-with-sacha-labourey-1_hd.mp4" /]

    — Alan Shimel

  • Cybersecurity Fears May Drive Shift to Managed DevOps

    Cybersecurity Fears May Drive Shift to Managed DevOps

    Should organizations consider using a managed service for DevOps to keep their platforms up to date and secure?

    The recent disclosure of a vulnerability that would allow open source Jenkins continuous integration/continuous delivery (CI/CD) platforms to be employed to launch a distributed denial of service (DDoS) attack highlights how challenging it is to secure the platforms on which many organizations now depend to build their most critical applications.

    The CVE-2020-2100 bug theoretically would have allowed cybercriminals to employ the Jenkins UDP discovery protocol to bounce traffic between servers until they could no longer respond. That same flaw also could be employed to launch DDoS amplification attacks against platforms connected to the internet. Those attacks can’t be stopped unless one of the servers is rebooted or its Jenkins service is restarted. The specific vulnerability discovered was fixed last month in Jenkins v2.219. IT organizations can either upgrade their Jenkins servers, disable the UDP discovery protocol or block the UDP port 33848.

    Tracy Miranda, director of open source community for CloudBees and member of the governing board for the Continuous Delivery Foundation (CDF), which oversees the development of Jenkins, said the bug itself is at best of medium severity. However, now that it’s been disclosed, the race is on to patch Jenkins servers or block UDP port 33848 before cybercriminals exploit the vulnerability on any public-facing instance of a Jenkins server.

    Given the fact that most IT organizations may not have resources at hand to patch their Jenkins servers quickly, Miranda said these and other potential future cybersecurity issues are a testament to why more organizations should rely on instances of Jenkins that are managed by third-party providers on their behalf. Organizations are spinning up more Jenkins servers than ever as they move to accelerate application development, and by relying on a managed service provider (MSP) to manage Jenkins, IT teams can focus more of their efforts on building and deploying applications rather than on managing CI/CD platforms.

    These days, more organizations are looking at DevSecOps as a best practice. Much of that focus, however, is on securing the applications that DevOps teams create; not nearly as much attention is being paid to securing the underlying platforms on which those applications are being built and deployed.

    It’s too early to say to what degree cybersecurity concerns might push IT organizations toward managed DevOps platforms. However, the more that cybersecurity teams participate in the DevOps process, the more they will ask questions about the fundamental security of the underlying platform.

    Of course, many IT teams often view managed services provided by third-party vendors as a threat to their existence. Nevertheless, DevOps platforms are among the most complex and expensive platforms to manage. In fact, that complexity is one of the main reasons so many organizations have hired site reliability engineers rather than relied on traditional IT administrators to manage DevOps platforms such as Jenkins. The issue that often comes up is just how many SREs an organization needs to hire before the cost of a managed DevOps platform becomes economically more appealing.

    — Mike Vizard

  • Wind River Launches CD Platform for Embedded Systems

    Wind River Launches CD Platform for Embedded Systems

    Wind River is fostering the adoption of DevOps processes for embedded systems by making available a continuous delivery (CD) platform that its customers can download.

    Glenn Seiler, vice president for open source strategy for Wind River, said the CD platform is based on an open source instance of the Jenkins continuous integration/continuous delivery (CI/CD) platform. The company envisions organizations downloading the platform as source code that Wind River will update regularly for use on top of the Wind River Linux platform, he said.

    Wind River is taking advantage of containers, Kubernetes, the Puppet IT automation framework and a repository to ease deployment of its CD platform, added Seiler. The company is committed to providing updates to that platform, which Wind River uses internally, at least every three weeks, said Seiler.

    Wind River expects most organizations will already have some form of a CI process in place. The CD platform provided by Wind River will focus on accelerating the delivery of applications built using whatever CI process organizations have in place today, said Seiler.

    In the embedded systems space, Seiler said the adoption of best DevOps practices is still in its very early days. However, with the rise of edge computing and the internet of things (IoT), organizations will need to find a way to securely deploy and update highly distributed application environments. To achieve that goal, many organizations will apply the same DevOps principles enterprise companies have been applying to their embedded systems, he said.

    To ensure the integrity of the software supply chain on which the Wind River CD platform is delivered, Wind River has also been certified under the ISO 9001:2015 specification for management processes, as well as the OpenChain specification for open source compliance.

    Wind River also has the Wind River Workbench for Linux LTS, based on the Eclipse integrated development environment (IDE), along with various system analysis tools including a trace visualization tool from Percepio AB to identify the root cause of anomalies.

    While it’s taken more than 10 years to drive the adoption of best DevOps practices in the enterprise, adoption in embedded systems environments should be faster now that the journey has begun. Organizations of all sizes are pushing more application workloads to the edge at faster rates. Traditional approaches to building and deploying applications on standalone embedded systems will not be able to keep pace. Organizations that build applications for embedded systems will be challenged by first acquiring the right tools and then adapting their internal culture to the complexities that arise when they need to build and deploy applications faster.

    Wind River is making the case for a curated open source CD platform that should enable organizations to spend less time on managing the underlying DevOps platform in favor of focusing more time and energy on changing their internal culture.

    — Mike Vizard

  • Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

    A new company, Launchable, aims to improve your delivery velocity by helping you be much smarter about which tests you run and when. By applying machine learning (ML) and better use of the data output by your software development work, the two co-founders think they can make a meaningful impact on development efforts.

    Sure, you say, lots of developers say they can change the world. But in this case, the co-founders have some very impressive résumés to give you confidence they just may do it. The dynamic duo is none other than Harpreet Singh, former GM of Atlassian BitBucket and VP of Product and Design at CloudBees, and the one and only Kohsuke Kawaguchi, founder of Jenkins and CloudBees Chief Scientist, most recently.

    Wait a second, you may be asking, you’re saying KK from Jenkins/CloudBees has started a new company? Yes, that’s what I am saying. In a podcast that will be available very soon, KK and Harpreet talk with us about Launchable’s why—and why now. Stay tuned for that.

    It’s worth noting that KK has been at CloudBees for 10 years and working on Jenkins for 15 years. In the tech business, that is nearly a lifetime. During our podcast, KK said he felt that with Jenkins being passed to the Continuous Delivery Foundation (CDF), coupled with a healthy group of leaders within the Jenkins community, now was a good time to move on to the next adventure.

    Beyond Jenkins, CloudBees has grown into its own next phase, with lots of exciting developments announced and more coming. The scientist in KK has led him to explore solutions to problems he sees in the way so many companies are doing development. His longtime friendship with Harpreet, dating back to their days at Sun, has energized them both to once again work together and tackle the real problems that development teams are facing.

    What will come out of Launchable? I don’t know. But the company has already attracted some blue-chip VC investment, as well as an impressive list of angels including Sacha Labourey, CEO and founder of CloudBees.

    They (like everyone else, it seems) are hiring development engineers and data scientists. So if working with KK is something that appeals to you, head over to the Launchable site and check out the Careers section.

    I am sure we will be hearing more about Launchable in the days, weeks and months ahead. In the meantime, best of luck to Harpreet and KK, and many thanks for a job well done with Jenkins.

    — Alan Shimel