Tag: Jenkins

  • How to Use the Jenkins Pipelines

    How to Use the Jenkins Pipelines

    With the introduction of the Pipeline, Jenkins added an embedded Groovy engine, making Groovy the scripting language in the Pipeline’s DSL.

    Here are the steps you need to take to set up a Jenkins Pipeline.

    1. First, log on to your Jenkins server and select “New Item” from the left panel:

    1. Next, enter a name for your pipeline and select “Pipeline” from the options. Click “Ok” to proceed to the next step:

    1. You can now start working your Pipeline script:

    The red box in the middle is where you can start writing your script.

    Creating the Jenkins Pipeline Script

    Pipelines has specific sentences or elements to define script sections, which follow the Groovy syntax.

    Node Blocks

    The first block to be defined is the “node”:

    A “node” is part of the Jenkins distributed mode architecture, where the workload can be delegated to multiple “agent” nodes.

    A “master” node handles all the tasks in your environment. Jenkins agent nodes offloads builds from the master node, thus performing all the pipeline work specified in the node block.  For more details, read about Jenkins Distributed builds.

    • This block is optional, and one could be considered as good practice, since with the code included in this block.
    • Jenkins will schedule and run all the steps once any node is available and creates a specific workspace directory.

    Stage Section in Jenkins Pipeline Build

    The “stage” section is required to segregate the work category as listed inline:

    A specified pipeline will consist of several steps that can be grouped in several stages. For example:

    Stage 1 Pull code from repository Pull Code CheckIn
    Stage 2 Build your project and artifacts Build Project/Artifacts of Project
    Stage 3 Deploy your application Deploy from centralized repo to specified environment
    Stage 4 Perform functional tests QA performance will happen
    Stage 5 Perform performance tests ·       (UI and performance can test.

    Note: Each of the these can include more than one action.

    For example, a stage to deploy your application can consist of copying the files to a defined environment for functional tests and to a dedicated server for performance tests/QA and once files are copied successfully, delivery process will start to deploy on any specified environment.

    Each stage block specifies the tasks to be performed:

    Stage blocks are also optional, but they are recommended because they provide an organized way of specifying tasks to be executed in the script.

    Pipeline Syntax

    This section builds on the information introduced in Getting started with Pipeline and should be treated solely as a reference. For more information on how to use Pipeline syntax in practical examples, refer to the Using a Jenkinsfile section of Jenkins chapter.

    • As of version 2.5 of the Pipeline plugin, Pipeline supports two discrete syntaxes, which are detailed below. For the pros and cons of each, see the Syntax Comparison.

    “Pipeline Syntax” to access the following page:


    “Generate Pipeline Script” will create the desired sentence that can be added to your script immediately.

    The Jenkinsfile

    Pipeline supports two syntaxes, Declarative (introduced in Pipeline 2.5) and Scripted Pipeline. Both of which support building continuous delivery pipelines. Both may be used to define a Pipeline in either the web UI or with a Jenkinsfile, though it’s generally considered a best practice to create a Jenkinsfile and check the file into the source control repository

    Jenkins Scripted Pipeline:

    • For more advanced usage with Scripted Pipeline, the example above node is a crucial first step, as it allocates an executor and workspace for the Pipeline. Since the Jenkinsfile is being pulled directly from source control, Pipeline provides a quick and easy way to access the right revision of the source code:

    The checkoutstep will checkout code from source control; scm is a special variable which instructs the checkout step to clone the specific revision which triggered this Pipeline run.

    Sandbox Security in Jenkins

    Jenkins limits the execution of any Groovy script by providing a sandbox. The option “Use Groovy Sandbox,” shown below, is available in the Pipeline tab, and it allows the scripts to be run by any user without requiring administrator privileges. In this case, the script is run only by using the internal accessible APIs (which allow you to develop your script by using Groovy).

    When unchecked, if the script has operations that require approval, an administrator will have to provide them. This method is known as “Script approval.” By default, all Jenkins pipelines run in a Groovy sandbox.

    If the option is checked and unauthorized operations are used, the script will fail when run. Both the whitelist and the blacklist of functions can be checked at Script Security’s built-in list.

    — Pramod Vishwakarma

  • CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees today signaled its DevOps ambitions to extend well beyond the Jenkins continuous integration/continuous deployment (CI/CD) platform by acquiring Codeship, a provider of a CI/CD platform that is delivered as a software-as-a-service (SaaS) application.

    The decision to acquire Codeship is being driven by the need to engage smaller DevOps teams that don’t have the time or expertise required to set up on-premises instances of Jenkins, said CloudBees CEO Sacha Labourey.

    Codeship today is being used by more than 100,000 developers spanning 2,400 customers. Many of those developers are working at smaller companies. But Labourey noted that small teams of developers inside larger companies also prefer to invoke a CI/CD platform as a service.

    “Different teams will decide to do different things in the same organization,” said Labourey.

    The Codeship platform is not based on Jenkins and there is no plan to rehost the Codeship service on Jenkins, says Laborey. Jenkins is designed to be highly customizable by the organization that employs it. The Codeship service is a highly opinionated instance of multitenant CI/CD platform that is designed to provide a turnkey experience capable of support lots of developers at once, explained Labourey.

    CloudBees will explore ways to bundle its core platform with the Codeship service for organizations that find themselves needing to deploy both a CI/CD platform on-premises in addition to a cloud service, he added.

    The acquisition of Codeship signals a wave of coming consolidation across the DevOps sector, Labourey said, predicting that over time, a much smaller number of companies will account for most of the DevOps software and services sold. Some will rise from the ranks of the pioneers of DevOps. Others will be the same companies that today dominate application lifecycle management (ALM) and software development lifecycle (SDLC) software in the enterprise. As DevOps continues to gain momentum in the enterprise, it’s now only a matter of time before legacy ALM and SDLC vendors are forced to modernize their portfolios by making acquisitions or partnering with companies such as CloudBees, he said.

    It’s too early to speculate how that consolidation might play out. But it’s clear the rise of microservices is about to force the DevOps issue in many enterprises. The rate at which DevOps processes have been adopted across enterprise has been uneven, but as organizations embrace microservices to build better applications faster, many will need to re-engineer their application development processes. There always will be monolithic enterprise applications that may be better-served by waterfall approaches to application development, but in time, the bulk of applications will be built employing microservices architectures that make it easier to update and manage applications employing modern DevOps best practices.

    How much those DevOps processes will be based on CI/CD platforms running in the cloud or on-premises is anybody’s guess. More than likely, most organizations will rely on a combination of both, depending on the size and scope of their efforts. Regardless of the approach, however, at a time when every company is becoming more aware of their dependency on software to compete, it will be those organizations that embrace DevOps processes best that will prosper at the expense of rivals.

    — Mike Vizard

  • Morpheus Data Advances DevOps Across Hybrid Clouds

    Morpheus Data Advances DevOps Across Hybrid Clouds

    Thanks to the rise of multi-cloud computing, the challenges associated with managing DevOps are becoming exponentially greater. Most IT organizations are not likely to be 100 percent sure at any given time which application workload is running where.

    To address that issue, Morpheus Data has added a Cross-Platform Discovery module to its Unified Ops Orchestration platform that employs machine learning algorithms to determine not only what applications, virtual machines and containers have been deployed on-premises or in a public cloud, but also how much capacity, memory usage and power consumption each is using and their and overall performance.

    At the same time, Morpheus Data is adding integration with Github and Jenkins continuous integration/continuous delivery (CI/CD) environments as well as support for both Docker Swarm and Kubernetes clusters.

    Finally, Morpheus Data has added connectors to IBM Cloud, Upcloud and HPE OneView services and been certified as a ServiceNow partner. The Unified Ops Orchestration platform already supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform.

    Brad Parks, vice president of marketing and business development for Morpheus Data, notes that as IT environments become more distributed in the age of the cloud, new approaches to change management will be required. The Unified Ops Platform provides an opportunity to consolidate change management processes within the context of a single control plane.

    While more IT organizations are making use of multiple cloud services, most are managing each IT environment in isolation. Over time, the lack of unification of the control planes for each of those environments conspires to increase the total cost of ownership for IT. Morpheus Data is making a case of for unifying the management of multiple platforms running on-premises or in public cloud instead of requiring IT staff to master multiple management tools.

    That single management plane, Parks says, also makes it much easier for IT organizations to take dynamically employ multiple cloud environments. Price points for cloud services are liable to change at any moment, but it doesn’t necessarily follow that the same type of workload will continue to be deployed on the same cloud. At the same time, the characteristics of a workload may have evolved to the point where it doesn’t make financial sense to deploy it on a public cloud. A common management platform makes it possible to move that workload with the least amount of disruption possible.

    Most IT organizations today are concerned about getting locked into a cloud service provider. Being able to demonstrate an ability to switch between cloud service providers gives IT organizations an opportunity to negotiate cloud service contracts from a position of strength. Most cloud service providers are counting on the fact that the cost of switching from one provider to another is simply too high. Integrated DevOps processes wrapped around a common management plane, however, will make it clear to all concerned that the platform provider serves at the pleasure of the internal IT department, not the other way around.

    — Mike Vizard

  • Total DevOps is Needed, Plugins are Not Enough

    Total DevOps is Needed, Plugins are Not Enough

    Trace3 was proud to be a Gold Sponsor, exhibitor, trainer of the DevOps Institute leadership certification course and newest partner of CloudBees at the CloudBees Jenkins World 2017 event in San Francisco last month. Jenkins World 2017 attracted 54 sponsors/exhibitors, an 80 percent increase over 2016.

    The growth of interest and sponsors for this event demonstrates that the number of available tool choices for creating the continuous tool chains to realize continuous delivery and DevOps is growing. One of our top takeaways from Jenkins World 2017 is: Plugins are not enough!

    Indeed XebiaLabs’ “Periodic Table of Tools” is a valiant attempt to illustrate categories of DevOps tools and attributes of specific tools. Version 2 of the Periodic Table is now released, and I heard that version 3 is already on the way. While the table shows an impressive 15 categories of tools, I estimate there are actually 29 categories, if you consider tools for cloud management, test management, test creation, code analysis, code collaboration, ALM systems, dashboards, security and others.

    XebiaLabs’ table shows five attributes for each tool: open source, free, freemium, paid and enterprise. In my opinion, there are at least two additional categories: ecosystem and cloud readiness. While the table indicates 120 tools, my own estimate counts 300+ DevOps tools, including CloudBees, Electric Cloud, Perforce, Scalyr, Service Now, Tricentis. SmartBear, SonarQube, Parasoft, Coverity, Fugue, QA Symphony and many others.

    While the exact number of tool categories, tools and attributes is arguable, there are many tools to choose for a continuous delivery toolchain. The state of practice for integrating tools into a seamless toolchain is the plugin or do-it-yourself scripting. Anyone who has implemented a toolchain knows that the existence of tool plugins, while useful, is not enough. The quality and completeness of each plugin varies significantly. Some off-the-shelf plugins are so basic they are little more than marketecture. Even the best plugins are limited to a pairwise matchup between tools of specific version pairs, and not a universal tool or version. For example, a tool with a plugin for Jenkins version X may not function with Jenkins version Y or CloudBees Enterprise of other tools at any version.

    The DevOps Express collaborative initiative announced by 14 participating vendors at Jenkins World 2016 was an attempt to resolve the plugin problem. One year later, the DevOps Express website has shown a growth to 123 tools across 18 categories. However, just like the XebiaLabs Periodic Table of Tools, it is remarkable that the number of tool categories and tools that are not comprehensive (and lacking plugin compatibility) are not guaranteed for any combination of tools that may be needed for a toolchain for a specific enterprise.

    Each enterprise has unique toolchain requirements and preferences. Selecting and an integrating DevOps tools is not like buying a box of “standard” Lego bricks that are guaranteed by the manufacturer to fit together. Each tool and plugin is different.

    The choice of tools, the combination of tools and the integration of the chosen tools all must be carefully chosen to fit the specific customer requirement. More importantly, the integration must be architected to ensure the chosen combination works well together in a seamless toolchain.

    Until there is an absolute standard plugin architecture that all tool plugins are guaranteed to be compliant with, expert consulting services will be essential to make tools choices and make sure the tool chain works.

    With such a rapidly growing list of tools and vendors, only the most capable consulting teams with deep insight and partnerships with the widest array of tool vendors will be able to address enterprise DevOps solutions properly.

    — Marc Hornbeek

  • Jenkins World, Training and Infostretch

    Jenkins World, Training and Infostretch

    I’ve talked to a fair number of vendors about Jenkins World 2017, and I’ve spent a decent amount of time lately supporting DevOps training initiatives at a variety of vendors.

    The thing is, the DevOps world is changing fast enough and there are enough options out there that training is not something you need only before moving to DevOps. During one recent project, I ended up learning about a particular topic as I was developing support materials for a training session on that topic. And I’m pretty steeped in the DevOps world.

    So, while I don’t write about every vendor I’ve talked to about Jenkins World, Infostretch‘s new training program is worth talking about. Infostretch is unveiling an array of training solutions to help companies not only get a handle on DevOps needs, but also to grow their DevOps maturity.

    Among the offerings will be a DevOps maturity assessment and new Jenkins training programs. In conjunction with its visit to Jenkins World, Infostretch will be offering a free 90-minute webinar on adopting Jenkins 2.0.

    Demands of the job will keep me from attending Jenkins World, but if you’re there, it might be worth checking out Infostretch’s booth (#415) to see what there is to learn. If you do, feel free to drop me a line—I’m intrigued to learn more about the training and how it fits in with other available offerings. As an added bonus, the company is giving away “Game of Thrones”-themed DevOps Journey Maps marking various stages of DevOps journey and the “happy flow” of DevOps, and including the various tools available in the market for each stage. So you can snag that while stopping by for me to learn about Infostretch’s training.

    The other thing that interested me was a presentation. Sanil Pillai, director of Infostretch Labs, will be presenting a 15-minute demo titled, “Auto-Convert Your Freestyle Jenkins Jobs to Coded Pipeline” on Wednesday, Aug. 30, at 10:45 a.m. at the Sponsor Theater, in the Expo Hall. The variety of scripts that can make up the components of a Jenkins build environment are a problem many of us have struggled with; while better than what we had because they’re part of an automated process, the components are still technical debt with variable maintenance requirements. Someone, please go see the talk/demo and report back. It would be cool if Infostretch has an answer for this problem.

    I Reiterate: Training is Imperative

    It is human nature to make a large change and settle in with the known new world. DevOps is not designed to be that way. It is still growing and changing, so don’t get complacent. Challenge yourself and seek out training, tool enhancements and opportunities to improve. As others have said repeatedly and well, DevOps is a journey, not a destination. Learn, get better, find better ways and tools and keep improving.

    And, keep rocking it. Eliminating IT as a bottleneck is a huge step to improving product development and being more in sync with the business.

    Of course, now that I’ve written out the reasons why Infostretch’s plans for Jenkins World interested me, I am tempted to dig into some of the other offerings. Or to try and figure out how to go to Jenkins world without missing important things at work.

    You may be hearing more of Jenkins World from me before it arrives.

    — Don Macvittie

  • DevOps Chat: Jenkins World Preview with Cloudbees CEO, Sacha Labourey

    DevOps Chat: Jenkins World Preview with Cloudbees CEO, Sacha Labourey

    Jenkins World, at the end of the month, promises to be the biggest and best yet. There could be upwards of 2,000 people at this year’s event. With a schedule full of training, sessions, keynotes and more, it is a don’t-miss event if you are into Jenkins, DevOps, CD and more. We sat down with Cloudbees CEO Sacha Labourey to discuss a Jenkins World preview.

    Sacha has guided Cloudbees on its journey in working with the Jenkins community while making the value of the Cloudbees offerings readily apparent. His past experience with JBoss has helped much. There is a Q&A with Sacha that we did as well, which has a lot more information.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Have a read or listen and hope to see you at Jenkins World!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat, and today’s DevOps Chat is all Jenkins World all the time. I’m joined by none other than Sacha Labourey, Labourey – I messed it up, but we’ll let Sacha pronounce it correctly. I only know Sacha about three or four years now and still can’t pronounce his name correctly, but, more importantly, Sacha is the CEO and visionary behind CloudBees. Sacha, welcome to DevOps Chat.

    Sacha Labourey: Thanks a lot, Alan, and my last name is a disaster to say for English-speaking person, so it’s “Labourey” – think about “Labor Day” and remove the “D,” but even that is hard to compute fast, so you did well.

    Shimel: Okay. Labourey. So, Sacha, we’re gonna talk about Jenkins World, and, for those of our listeners who aren’t aware, Jenkins World 2017 is coming to San Francisco. It’ll be at the Marriott Marquis Hotel there, right in downtown. And the conference runs from August 28th through August 31st. There’s so much planned this year, but, Sacha, this is – what? – the third or four, maybe more, Jenkins World that you’ve done?

    Labourey: Yeah, actually, I was looking at some of the numbers. I remember the first edition, probably – I’m not even sure if it was called “Jenkins World” back then, but, in 2012, we had 200 persons attending and we’re extremely proud of this, obviously. If you remember, the Jenkins Project was relatively new – it had just changed names in 2011 – so 2012 was 200 people. And, this year, we’re expecting at least 10X that number, so it’s gonna be a massive event in San Francisco.

    Shimel: Yep. And for our math-challenged friend out there, 10X of 200 is 2,000. And –

    Labourey: I think so, yes.

    Shimel: Yep. And, even comparing last year, Sacha, to this year, I think – I mean, last year was the biggest year ever done and I wanna say it was around 1,300, 1,400, something like that.

    Labourey: Yeah, absolutely. So it’s a big jump. You know, it’s almost 50 percent more than last year, so it’s a big step forward.

    Shimel: Good and congratulations on that. I think it’s testament, though, Sacha, to both the popularity and usage of Jenkins, as well as CloudBees. Right? And, you know, it –

    Labourey: Yeah –

    Shimel: Yep. Go ahead.

    Labourey: Yeah, you’re right. I think it’s like the perfect wind condition, you know? It’s, on one hand, you have DevOps maturing and being on everybody’s to-do lists, and so a lot of people wanna know more, wanna learn, want to share their experience. Jenkins is doing extremely well, as a project. Lot of new features in the last few years, you know, starting with Pipeline, Blue Ocean, and so on, so that makes it a very hot topic.

    And I think CloudBees, as you said, we’re doing extremely well as a company and we’re obviously extremely active in that field. We’re working a lot with the Jenkins community – I know you wanna talk about that, at some point – and so, yeah, I think it’s all of those different winds coming together and making that amazing conference.

    And, you know, we talk a lot about the numbers, right? Obviously, 2,000 people or above – it’s gonna be an amazing conference – but it’s also the quality of the content, the number of tracks and so on. This year is really gonna be a step up from last year, which was already an amazing conference.

    Shimel: Yep. Let’s talk about speakers and stuff for a second, if we can, Sacha. Obviously, you’re there and you will be doing one of the keynotes – I guess it’s the first day of the conference, right? The 30th?

    Labourey: Yeah, I’m gonna – yes. I’m gonna be one of the keynote, yes.

    Shimel: And, without letting the cat out of the bag and making new news here, can you give our audience maybe just a little bit of an idea of what to expect or what topics, areas you wanna cover, as part of your –

    Labourey: Yeah, absolutely.

    Shimel: – talk?

    Labourey: Yeah, the good news is, first, I’m not gonna be singing or dancing or anything like that, so you should be safe. And from a –

    Labourey: – from a content – [chuckles]

    Shimel: Uh-huh?

    Labourey: – from a content standpoint, obviously, like I try to do every year, we’re gonna be doing kind of a “state of the union” on what happened and where things stand, what we’ve learned, what works, what doesn’t work maybe, and show so a vision for the future. And the vision needs to be multiple years ahead, but it also need to be actionable, practical, and so we’re gonna be talking about some of the new things we’re gonna be announcing at Jenkins World, some amazing features. It’s gonna be great timing when you look at the maturity of DevOps itself. The type of requirements and needs from DevOps people also evolved with the other whole maturity of the space, and so I think we’re gonna have some pretty significant announcements that week that will fly very, very well with the community there.

    Shimel: Great. And then, in addition to yourself, Sacha, of course, Kohsuke – you know, KK – will be speaking and I’m sure everyone in the Jenkins and CloudBees community will be looking forward to that. He’s kind of revered within the community there, right? So…

    Labourey: Yeah. Every year, KK – so Kohsuke is doing his keynote and so he’s – I’m taking more of the business angle and the impact on the businesses; KK is obviously taking the community angle and the evolution of the project. And, when you look at KK, you see – you know, you perceive somebody who is not shy but pretty reserved, as a person, but I can tell you, when he’s on stage every year, it’s such a pleasure to see him there and make his status of the union, go through the numbers, and he’s a lot of fun. He’s really, really fun on those keynotes, so I’m really excited about this one.

    Shimel: Yeah. I mean, I’ve had the pleasure of watching KK present at a lot of the Jenkins Days and CD Summit roadshows that we did, over the last couple years. And I will tell you, you know, I think he kinda feeds off the members of the community and they, in turn, kinda feed off of him, so it is a great thing. I wanted to just also briefly mention another keynote speaker that you guys will be featuring at Jenkins World, and that’s my friend Jez Humble.

    Labourey: Yes, absolutely. Jez accepted to come and talk as a keynote speaker. Very excited as well. He makes great presentations. He has unique insights into this market, this transition, so I’m extremely excited about Jez Humble’s presence here.

    Shimel: Yeah. And, of course, Jez – I mean, Jez literally wrote the book Continuous Delivery, as well as the Lean Enterprise, and Jez is also a cofounder and, I think, working full time now with DORA, DevOps Research and Analysis, along with Gene Kim and Dr. Nicole Forsgren. So he had some great insight. You know, they surveyed something – I think it was 25,000 or 27,000 people over the last – or organizations over the last 4 or 5 years, and it really – I mean, again, great, great presentation.

    Sacha, if we can, while we’re on topic, you brought it up earlier or mentioned it, but I wanna really kinda bring it home for our audience, and that is that, yes, this is Jenkins World. It’s about Jenkins. Jenkins is an open-source project that, literally, millions of people are involved in, in one way or another. And CloudBees is intrinsically linked to Jenkins, right? But the relationship between CloudBees and Jenkins, Sacha, how do you explain it to our audience?

    Labourey: Yeah, you’re right. It’s a very important topic and I think we feed the community, the community feeds us. I think there is a very healthy relationship there. First, I think every company-slash-open-source-project behaves in a slightly different fashion. You know, I used to be at JBoss, at Red Hat, so we had already, in two companies, very different ways to interact with open-source communities and build a business on top.

    At CloudBees, I would say, we have yet another way to do that, and it’s really this church-and-state separation and the community’s the community. We obviously have an impact on the community because we’re pretty massive contributors to the project, but they are independent. They have their board; we provide requests that get approved or sometimes denied. So I think it’s very healthy to have this independent community and you can see it through the massive community beyond the Jenkins core itself, right? We’re talking about more than 1,400 different plug-ins, and each of those plug-ins are kind of like mini-communities around the project, so it’s a pretty massive ecosystem out there.

    And so, obviously, as a company, we leverage these install days and the power of this install days and help enterprises adopt Jenkins at scale and get insight into their installation and so on. But the community’s also benefiting a lot from, I think, CloudBees’ involvement. We’ve been massive contributors and initiators of projects like Pipeline; like Blue Ocean, the new user interface. If you look at some of the security issues that have emerged in Jenkins, much like in lots of Java programs out there, CloudBees has stepped up and spent – top quality engineers that have spent their weekends and weeks fixing a number of those. And that’s for the good of the community; that’s for the good of everybody. And, if CloudBees was not to do that, well, I’m not sure who else would be doing it, so I think, yes, there is a very healthy sharing taking place here, and I’m very proud we’ve been able to put that in place.

    Shimel: Excellent. Sacha, let’s turn a little bit – I said earlier on that the Jenkins World is August 28th through August 31st. The sessions, the keynotes, the exhibits – those are August 30 through 31st, but trainings and workshops actually start August 28th. And I wanna say the 30, 31st is a Wednesday, Thursday, and I believe the 28th is Monday, Tuesday.

    Labourey: Correct.

    Shimel: And there’s a whole lineup of training – some of it’s sold out already, but there’s a whole schedule of, I think, Jenkins training, Jenkins certification, and not just one curriculum of the same class being repeated. There’s a deep bench of different Jenkins training sessions and workshops available, correct?

    Labourey: Yeah. And, last year, that was already a huge success, so, this year, we’ve made sure that we have even more training course available, even more seats, but that’s a big, big one. And think about it. Obviously, for people who live in San Francisco and the Bay Area, it’s a relatively easy one to attend Jenkins World – it’s almost like a no-brainer – but we actually have a pretty important number of people traveling from the US but also from APAC or from Europe, and, for those people, it’s very important to make sure that they, quote unquote, don’t “just” attend the conference, and, way this layout are just laid out, you have a way to get trained, to get ready to be certified, which is great for your career. You get to attend workshops. So it’s very hands-on. You really come back and learn, have something you can factually show on your resume to your boss and explain that you’re really, you know, one, two steps above from where you were the week before, so it’s a great combination to come the weekend before, spend a few days doing training and workshops, and then attend the conference, meet with people, share expertise and so on, so it’s an amazing pack, I think.

    Shimel: Yeah. No, it’s a great opportunity. I mean, I should also mention that the DevOs Institute, partnering with CloudBees, will be offering some certification classes on the 28th and 29th at Jenkins World as well. I think they’ re gonna be offering the continuous testing engineer class, taught by Mark Cornbee, who wrote the curriculum, and I think they might be debuting “DevOps Leader,” which is aimed for people who wanna lead the transformation, and that’s a great class as well. I’m not 100 percent sure. If you go to Jenkins World, to the website on CloudBees, the Jenkins World section, you could see the DevOps Institute classes, as well as all – and, as I said, there’s as deep bench of CloudBees and Jenkins training available the 28th and 29th, and there are some workshops as well, I believe, on the 30 and 31st, for maybe people who just can’t get there all four days.

    Sacha, I wanted to talk about some of the other sessions that are gonna be on for the 30 and 31st. One, you know, shameless, I’ll promote – I’m actually moderating a DevSecOps panel on the 31st. I believe it’s at 10:30 in the morning. And that one will feature Rob Stroud of Forrester – I think Rob’s gonna be on a number of panels and sessions at Jenkins World. I’ll also have several of my friends from the security community, including Pete Chestna of Veracode, Andrew Storms of New Context. I think Andrew Wallgren, CTO of Electric Cloud, will be joining us. Derek Weeks or Curtis Yanko of Sonatype, and Pathik Patel, I believe, also. So that’s gonna be a great panel, but, Sacha, what panel or session would you – you know, give us three sessions, if you will, that maybe you’d like to recommend to our listeners.

    Labourey: Well, so there’s gonna be some special tracks on finance, for example, and I think those will be very well-received. We see a big interest from specific verticals, interested in sharing expertise, right? So, you know, I was just looking before, you have the Federal Reserve Bank of New York was gonna talk about their path to DevOps, so those are pretty amazing presentation, I think. DevOpsSec – obviously, there’s gonna be your presentation, but there is more to it. DevOpsSec is – I’m not gonna be arguing with you on this – it’s a very hot topic, so quite a bit around DevOpsSec coming up. That’s very interesting. And I think, also, a lot around testing. A lot of companies are interested now in automating testing – that’s still the part that adds the most friction to their delivery pipeline – and so you’re gonna see a lot of great presentations around testing there.

    Shimel: Great. Looking forward to that. Sacha, we’re almost out of time, unfortunately – it goes really quickly – but I just wanted to make sure we hit everything. People can still register for Jenkins World, right, if you go to cloudbees.com/jenkinsworld, home –

    Labourey: Absolutely. Yes, yes. The time is now. And it’s the right time, if you’re traveling, to think about it. You have to book your hotel; you have to book your plane. So don’t wait until the last minute to do it. Absolutely. Now is the time.

    Shimel: Yep. One other thing I wanted to quickly mention, something I’m really looking forward to, is, like last year, devopsy.kinsta.cloud will have a video broadcast booth set up on the show floor – we’re gonna be upgrading it a bit this year – but, on the second day, we’re actually gonna do a CEO panel, and, Sacha, you’re kind enough to join us, and we will have Rob Stroud again from Forrester there, as well as a few other CEOs. And we’re gonna do a wrap-up, really, of Jenkins World and the state of DevOps and CD and CI and where we are in the market, from a CEO’s perspective, so, for listeners, you know, that’s something – it should be up within a few days after Jenkins World. I highly recommend you listen in on that to get that CEO perspective.

    Labourey: Yeah, we’re gonna have some big names there, so it’s very exciting.

    Shimel: Yep. Should be fun. Sacha, before we wrap up, anything we left out about Jenkins World or anything else our listeners should be aware of?

    Labourey: Well, if you’re into DevOps, you can’t miss that event. That’s the only thing I wanna say. Just think about the amount of training, of workshops, the number of valid tracks you can attend. If you’re really serious about DevOps, it’s part of your job. Really, this is gonna be the conference you need to attend, so now is the time. Let’s go.

    Shimel: Okay. And, listeners, if you go through devopsy.kinsta.cloud, use the code “jwdevopscust,” so that’s J-W-D-E-V-O-P-S-C-U-S-T. I’ll put it in the show notes of the thing and maybe that’ll help, but, if you do, you’ll get a 20-percent discount, and everyone can use a 20-percent discount, that’s for sure.

    Labourey: [Chuckles]

    Shimel: Anyway, hey, we’re gonna call it wrap on this episode of DevOps Chat. Sacha, thank you so much for taking time out your – I know it’s later in your day over in Europe, and we will see you in San Francisco in just a few weeks.

    Labourey: All right. See you there, Alan. Thanks a lot.

    Shimel: Okay. Sacha Labourey, CEO, CloudBees, talking to us about Jenkins World. I’m Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. Thanks, everyone, and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    Blue Ocean brings easy-to-use continuous delivery for teams to everyone. Years in the making, Blue Ocean is a major project built from the ground up for Jenkins Pipeline. I had a chance to speak with two of the key contributors from CloudBees and the Jenkins community, James Dumay and R. Tyler Croy. Tyler is on the Governance Board for Jenkins.

    Blue Ocean provides:

    • Sophisticated visualizations of CD pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
    • Pipeline editor makes creation of pipelines approachable by guiding the user through an intuitive and visual process to create a pipeline.
    • Personalization to suit the role-based needs of each member of the team.
    • Pinpoint precision when intervention is needed and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
    • Native integration for branch and pull requests enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.

    As usual our conversation in the streaming media player is immediately below.

     Streaming Audio

    Transcript of our conversation

    Alan Shimel: Hey everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Welcome to another DevOps Chat. We have two guests today on DevOps Chat. We have James Dumay and R. Tyler Croy of the Jenkins community. James, Tyler, welcome to DevOps Chat.

    James Dumay: Nice to be here, Alan.

    R. Tyler Croy: Thanks for having us.

    Shimel: Thank you. Let’s start off though with just a little background of each of you. James, you’re coming to us all the way from Australia. In deference to the distance, we’re going to let you go first. Why don’t you share with our audience a little bit of your background?

    Dumay: Yeah, sure thing. So I’ve been probably building development tools for the last 10 years. I think I’ve found my calling here. I love making developers more productive. I also want to make developers happier. So I do have this bee in my bonnet that developer tools are difficult when they’re boring and they’re not very pleasing. It’s my life’s mission to turn that around.

    Shimel: Excellent. Tyler, how about you?

    Croy: I’ve been with the Jenkins project a little over eight years now. I started using it when I was a back-end services engineer, a few startups ago. Every single company that I’ve joined needs more continuous delivery or some non-zero amount of continuous delivery stuff. So I found myself getting more and more ingrained in the Jenkins project and bringing Jenkins to bear in companies to ship products faster. Now I work at CloudBees talking about how you can do that and help other people see the light with some of the Jenkins stuff I’ve been doing for a while.

    Shimel: Tyler, I don’t want to embarrass you. You actually are—I don’t even know the word, but you’re one of the—on the steering committee or the governing committee for Jenkins. Is that the right way to put it?

    Croy: I guess you would say I’m on the Jenkins governance board. In the beginning of the Jenkins project, there was Kohsuke Kawaguchi who was the founder of the project, and then there are a few other core folks that were floating around that helped get Jenkins off the ground. Andrew Bayer who is a major contributor to the pipeline toolset, is one of those people. So I’ve just—Jenkins became a really important part of my life. I started spending a hell of a lot more time with Jenkins, and now I’m one of the people that makes sure that the project continues to move forward.

    Shimel: Excellent. James, I don’t know if you mentioned your role other—at this point, other than you’re cuckoo for Jenkins. What exactly is your role right now?

    Dumay: I’m director of Product Management at CloudBees, but I’m also a community leader for the Blue Ocean project. I do all the outreach and talk to all the users. It’s good fun, but previously before I was at CloudBees, I was at a small Australian startup called Canva. They do an online design tool. Prior to that, I spent seven years at Atlassian, where I was product manager for actually a competing product.

    Shimel: Absolutely. Well, we’re allowed to have competing products. They may not be any good. I’m only kidding. James, you mentioned the magic word. You get the first prize today. That was Blue Ocean. Today’s a bit of a—more than a bit—today is a big day in the Jenkins community. This release has been highly anticipated. It’s been in beta and in testing, alpha before that for some time. Talk to us. What about it? Why should people care?

    Dumay: All right. That’s a big question. So I guess we’re living in a really interesting time in the industry. We have this—there’s this ride of exponential change that is happening across our industry, whether it’s tooling and technology and process, or just the raw number of people writing computer software in the—we’ll be in the year 2020 soon. I think if you look back in the previous 10–20 years, the amount of companies out there that are writing software today and were not writing software 10 or 20 years ago. So Marc Andreessen speaks about software eating the world, where all the value that companies provide slowly but surely are being made, not by the engine in a Ford motor vehicle, but it’s the software on board the Ford motor vehicle.

    So it’s an interesting time to be a software developer, or to be in this field, but it’s also a really interesting time to be a tools creator. I think with this increase of people in the industry—it’s not like we have lowered the bar to what we call a software developer, but I think there’s a lot more people today who, in their jobs, whether it be financial services, or in other industries, who are finding their job involves writing software. I think there’s a big challenge here, and Blue Ocean is founded on going out there and solving this problem, that how do we make the millions of software developers or even people who are just writing software as part of their jobs, how do we make them more productive? How do we make sure they can get what they need to get done as quick as they can get it done at the highest quality that they can get it done with the best tools possible?

    So with Blue Ocean, we’re sort of focused in on the practice of DevOps and on continuous delivery. We set ourselves a goal. What if we can make it really easy for people to adopt continuous delivery? Blue Ocean is our answer to that.

    Shimel: Tyler, James—I think James made some important points. What can you add there? Why—let’s step back a second. Let’s say our audience is vaguely familiar with Jenkins. Most of them probably use it, but there’s some maybe that don’t. What is—let’s start with what is Jenkins to them? What does Blue Ocean represent to Jenkins?

    Croy: Sort of at a high level, Jenkins is an automation server. Jenkins is probably the most well-known tool of its kind across the entire software industry. As far as helping developers build and test and deploy their software, chances are with most organization today, if someone doesn’t think they’re running Jenkins, they might just not be aware, or they might be so far removed, or that it’s hiding, that they don’t know that it’s actually there. It’s pretty omnipresent in the industry right now.

    One of the big things about I would say the shift in the industry that has made Blue Ocean important—when I first started in northern California about 10 or— [inaudible] 10 years ago, continuous integration was this really big, important thing. I kept coming to companies who either didn’t have a continuous integration server, or didn’t practice—nobody but the developers knew that there was a continuous integration server. As the industry has shifted towards this more and more rapid pace of “Let’s practice continuous delivery. Let’s get product and value to our customers as soon as possible,” it’s no longer acceptable for just the developers to get feedback to what’s going on in that process.

    So I think the important thing for Blue Ocean, and I would say broader software industry, is that continuous delivery is not a developer thing. It’s an entire team thing. It’s an organizational thing. Blue Ocean is designed from the ground up to make sure that people who might not be writing code every single day, or they might be designers, or they might be product managers, or stakeholders of some form or fashion in the software development process. They need to know what’s going on and Blue Ocean is going to give them a window into what’s going on in the delivery pipeline. That’s a pretty dramatic shift from the Jenkins that was created 10 years ago, which was just for developers.

    Shimel: Got it. Got it. Now guys, I’ve had the—I don’t know if the word is a pleasure, but I’ve had the—well, it was a pleasure in a lot of ways, but I’ve had the experience of being involved with open-source projects in the past. It’s a fickle thing being part of a community. It’s even harder when you have a corporate entity such as CloudBees in this—CloudBees isn’t alone in this. There are many companies that are mentoring, managing—whatever you want to call it—open-source projects. Talk—I loved what I saw of how that relationship was handled as it applied to Blue Ocean.

    Guys, can you give us a little color on that? No pun intended with Blue Ocean and color, but a little background on how you worked with the community to deliver, I think, what the community consensus was what was needed.

    Dumay: Just to preface this. So this is my first time working full-time on behalf of the commercial entity for _____ community. So I—when we started at Blue Ocean, I kind of put myself in Tyler’s very capable hands. Tyler had had a lot of previous experience, not with Jenkins, but with other projects, walking that fine line between community and the need for the business sponsor, I guess. So it’s been an interesting process. I think certainly for CloudBees, a healthy Jenkins community is a healthy CloudBees, and a healthy CloudBees is a healthy Jenkins community. It all feeds into each other. As long as, I think, we take things from a project perspective, like what’s good for Jenkins, we’re making good decisions in both aspects.

    Certainly, we had been running—more in terms of Blue Ocean itself, we had been running for multiple years Jenkins community surveys, and one of the top issues people would have liked to see addressed in that feedback had been the user experience with Jenkins. They really wanted it to be easier to get started. They really wanted clarity when they’re looking for particular cases, information. I think there was a real groundswell there to see some improvements, and see some sort of more modern thinking around how to solve problems. I hope that we’ve done that. Certainly the feedback that we’ve been getting from the community has been pretty great.

    Just on the community itself, I think software developers can be a pretty passionate tribe of people. So it’s—the Jenkins project is no different from the wider developer community. They’ve been passionate in a very encouraging way, in a very forgiving way as well. Particularly when you go ahead and think about any product that has—web product that has been redesigned. So the people get very upset. They’re very invested in the tools that they use, or the products that they use, and then you move their cheese, and people go “Where did that thing go? Where did this other thing go? No. I was using that. Bring it back.” I think with the Jenkins community, I think they’ve been very—I think they’ve wanted the change for so long that as things change, we—they’re getting some new goodies in their bag and they’re happy to let some of the old bits disappear.

    Croy: I think there’s also—if you look at that feedback from the Jenkins user list going back years and years and years, there’s been—most people, I would say, that contribute to the Jenkins project, note they’re new, I guess past tense, because Blue Ocean is one meadow now—knew that something needed to get fixed, and someone needed to do something to really improve and set up Jenkins for the next 10 years. The skill set and the passion and the vision really wasn’t there.

    So when James and his team, his colleague Michael Neale and some of the other people, really started to get involved, I think it was easier for other contributors in the project to rally around that. It was clear that not only did they know what they were doing, but they understood the challenge in that we needed to think about the design from the ground up, as opposed to reskinning or reseaming Jenkins. They needed to evaluate it from a user experience standpoint and start from 2016 rather than 2006, which is when the project really started. So I think that was really helpful to have some—a passionate group of people with vision to drive it forward.

    Shimel: A passionate group of people with vision can accomplish a lot. That’s for sure. Guys, let me ask you—we’re almost out of time. What—for each of you, and we’ll go with James first. James, what do you think is the single biggest aspect or feature of Blue Ocean that our listeners should take a look at?

    Dumay: That’s very unfair, Alan. I love them all.

    Shimel: How can a parent decide? But guys, so pick one. Doesn’t have to be your favorite or biggest, but one that we’d like to call out.

    Dumay: The official pipeline editor. So _____ delivery pipeline is difficult at the best of times for people to create. So we set ourselves a challenge. What if we could make it very easy for people to create a continuous delivery pipeline using Blue Ocean UI. The one thing I really like about it is it really is for everyone. We talk a lot about—we’ve got a lot of plans for the Blue Ocean in the future. One thing we talk about is the Fisher Price’ing of the editor. I don’t know if you’re familiar with Duplo blocks you give a toddler. But you can get all these different attachments, all these crazy things, and you can customize your own creation using Duplo. It’s non-checkable Lego. So really, Duplo is for everybody. So anybody of any age can—of any skillset, can construct something from Duplo.

    The thing that I like about the—I guess the vision behind the editor is anybody can construct a continuous delivery pipeline, even if they don’t have coding knowledge. Maybe they want to take—they have—we can go as far as they can have a PHP website on a Dropbox folder and they want to upload that, deploy that continuously to their webhost, their DreamHost or something like that. That’s the kind of—we want to bring continuous delivery to everyone.

    I think the communal pipeline editor is the vehicle to do that. One of the great things about the editor as well is that it is what you see is what you get. So when you build it in the editor, that’s exactly how you visualize it later on in Blue Ocean, as that pipeline is executing. It’s really powerful in that way.

    Shimel: Great. Makes sense. Tyler, how about you?

    Croy: So my interactions with Jenkins are typically when something goes wrong. I think that’s maybe a bit more common for an infrastructure administer or developer. So, for me, I would say the No. 1 killer feature with Jenkins—with Blue Ocean and Jenkins is that the clicks to get from a failure or something going wrong to seeing what actually went wrong, it’s pretty much one click. So the visualization of status is so much faster and more immediate in Blue Ocean that when I come to Blue Ocean to figure out what test failed, or what went wrong in my pipeline, I get that in a matter of seconds, as opposed to drilling around and hunting through console help. So for me, that’s probably the killer feature.

    Shimel: Make sense. Guys, we’re going to wrap up here in a moment, but just quickly, for people who want to find out more about Blue Ocean, where can they go? James, Tyler?

    Dumay: No problem. They can go over to Jenkins.io/projects/blueocean or the Jenkins blog, which is Jenkins.io/blog.

    Shimel: Okay, Tyler, I’m going to hit you with the last question. Now that Blue Ocean is 1.0, what’s next?

    Croy: [laughter]

    Shimel: [laughter] You didn’t expect to get a rest, did you?

    Croy: No, no. I think the really important thing that’s next for the Jenkins project is I would say the next three months of Jenkins pipeline and Blue Ocean adoption. Now that we’ve got the tools that we’ve brought to the broader software industry for building and constructing and running continuous delivery pipelines, we’re going to need to iterate, on them and we’re going to need to make them better as more and more people start to adopt continuous delivery. I think we’re, certainly before the end of the year, we’re certainly going to find new things that we can add into Jenkins to make that an even more enjoyable experience.

    Shimel: Absolutely. Hey guys, congratulations. I know it’s easy on release day to say something came out. There was a lot of work here, an awful lot.

    Croy: Indeed.

    Dumay: Very much so. Thanks.

    Shimel: Thank you, James, Tyler, great job. R. Tyler Croy, James Dumay of CloudBees and Jenkins talking about Blue Ocean, the big news around Jenkins and CICD Pipelines. Guys, thanks very much. Hopefully we’ll have you back soon on another DevOps chat.

    Croy: Thanks a lot. See you later.

    Dumay: Thanks.

    Shimel: This is Alan Shimel with DevOps Chat. We’ll see everyone soon on another DevOps chat, but until then, have a great day.

    — Alan Shimel

  • From a Commodore 64 to DevSecOps

    From a Commodore 64 to DevSecOps

    We all know the story: a farm, a kid, a Commodore 64, and a modem maxing out at 300bps. A few unexpected phone bills later, and young Ian Allison is figuring out how to game the system so he can keep using his newfound gateway to the world of tech. According to Ian, that is where he began building the foundation of skills for his career in computer security.

    At the recent All Day DevOps conference, Ian (@iallison), now with Intuit, talked about his history of being “that” security guy. You know, the one who thinks developers don’t care about security or deadlines and, really, are just plain “stupid.” But, don’t worry, he is enlightened now and realizes that we all have the same goal: Everyone wants to build a secure system.

    Ian realized that “security doesn’t understand how developers or operations works. Security solves for security, but that leaves everyone else in their own place.” He started his enlightenment when his career path led him to a place called DevSecOps; that is, DevOps where security plays a more integral role.

    Ian pointed out that traditional InfoSec relies on compliance, regulations, appliances and perimeter (CRAP). He then realized the selfishness of his own and his peer’s perspective: Remediation is left up to the developers, the feedback they get are 200-page scanner reports, and it only solves problems for security and compliance. It doesn’t help developers reach their shared goal of a secure system.

    DevOps creates an opportunity for security to get a better view into our infrastructure, operations and development efforts.  DevOps is not only fast, lean and efficient, but when done right, it is also collaborative and empathetic. Couple speed with collaboration and empathy, and DevSecOps can blossom.

    Here is the reality that Ian was facing: Scanners find the absolute bare minimum; bad default configs are a HUGE problem even with SaaS vendors; manual testing can uncover defects that have been hiding for year; and the attackers are more skilled and motivated.

    How do you implement it and make it better?

    • Allow Dev teams to assume the risk of their decisions.
    • No more Security exceptions or signoffs.
    • Security is everyone’s responsibility.
    • Test the crap out of your own stuff like an attacker would.

    At Intuit, Ian wanted to help build stronger bridges between development, operations and security teams.  To do this, he set up a Red Team to:

    • Use same tactics as attackers.
    • Only scope is “Don’t take down production.”
    • Need to adapt and evolve like an attacker.
    • Prove risks actually exist.
    • Should be writing their own exploits.
    • Should have ongoing campaigns that mimic attackers.

    The Red Team started small and lean and focused on the cloud. It worked like an Agile DevOps team, working manually with the use of some tools. In the end, the team found, reported and fixed thousands of vulnerabilities not found by scanners.

    Ian goes into more details and lessons learned in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free-of-charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted more than 13,500 registered attendees. Last week I discussed, “System Hardening with Ansible.” Next week, look for my review of an awesome session by Erlend Oftedal:  “There is No Server: Immutable Infrastructure and Serverless Architecture.”

    — Derek E. Weeks

  • One Team, 5,000 Jobs: Life in the DevOps Jungle

    One Team, 5,000 Jobs: Life in the DevOps Jungle

    Damien has 5,000 jobs. While you might gasp at that workload, Damien is not stressing out. All 5,000 jobs are automated within his team’s Jenkins pipelines. How does he do it? Damien follows four key principles to keep his cool in the job jungle: self-service, security, simplicity and extensibility. But you might be surprised that one of his most important survival techniques is treating his pipeline as “not code.”

    At the recent All Day DevOps Conference, Damien Coraboeuf (@DamienCoraboeuf, nemerosa.com) discussed how his organization got out of the job jungle. Even with 5,000 jobs in Jenkins, Damien has a tiny team of six running it while supporting a large band of developers around the world.

    During his session, Damien laid out how a pipeline, the backbone of a Jenkins job, is constructed. Spoiler alert: It is pretty simple; hence, the magic of Jenkins. However, it gets complicated quickly, so Damien shared four principles his team strives toward:

    • Self-service. They don’t want the Jenkins team to be a bottleneck, and they don’t want to have to deploy an army just to run Jenkins.
    • Security. With teams of developers—many of whom they have never met—security and control is critical.
    • Simplicity. Developers can focus on developing rather than Jenkins.
    • Extensibility. As they grow and capabilities are dreamed up or implemented, their system needs to be able to adapt.

    Core to their implementation and their goals of self-service, simplicity and extensibility is the Job DSL Plugin. While Jenkins has a robust user experience, as jobs are added, it can get cumbersome and clumsy. The Job DSL Plugin brings order, automation and consistency to the jobs. Damien walks through the basics of the plugin and its benefits, noting that it treats the pipeline as code.

    Treating the pipeline as code allows the team to reuse code through versioned libraries and easily manage thousands of jobs. Requiring developers to manage more work as code does offer benefits, but giving that many people access to the code also produces security risks. So, Damien’s team actually treats the pipeline as “not code” by describing the pipeline using properties files. It also allows them to use the pipeline as metadata, so queries and reports are almost enjoyable.

     

    Damien’s team also utilizes the Seed plugin, which they maintain, to “help automate the generation and management of pipelines,” tighten security by keeping projects locked to teams and increase automation through hooks.

    The Seed plugin shares some functionality with the popular Pipeline plugin, which is maintained by a large community. However, the Pipeline plugin does not allow for treating the pipeline as “not code.” Damien’s vision is that one day Seed will be an extension of Pipeline.

     

    Damien’s team has done a tremendous job of running Jenkins across the enterprise. In fact, he just wrote me with an update that since November, his company has scaled to 7,000 jobs while still following the same principles.  If you want to learn more about how his team does it, be sure to watch his full All Day DevOps conference session (only 30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free of charge, here.

    — Derek E. Weeks

  • Confessions from Fannie Mae, Liberty Mutual and Capital One

    Confessions from Fannie Mae, Liberty Mutual and Capital One

    Learn from real-world stories from presenters at the All Day DevOps conference …

    True Story

    Over the past few years, Fannie Mae transformed the way in which it delivered software. Deploys increased from 1,200 per month to 15,000 per month.  At the same time, productivity increased by 28 percent while costs were reduced by 30 percent.

    But, how did Fannie Mae do it?

    During the All Day DevOps conference, more than 13,500 practitioners from around the world came together to learn from their peers in the industry. Barry Snyder, senior manager of DevOps at Fannie Mae, was one of 57 practitioners who shared his real-world journey through his enterprise transformation.

    Choke Point or Checkpoint?

    Eddie Webb, director of Software Delivery Platforms at Liberty Mutual, also shared his organization’s journey into DevOps.  Eddie described how Liberty Mutual evolved its organization, tool chain and processes to go from 20 percent of builds being deployed to 60 percent over the past 18 months. He described how the company documented its value delivery chain and identified all of its choke points in the continuous delivery process that would need to be automated to achieve its new velocity and quality targets.

    Screen Shot 2016-12-05 at 11.35.04 AM.png

    Run the Gauntlet

    The All Day DevOps conference recorded more than 57 practitioner-led sessions (30 minutes each) including those from Barry and Eddie. Every session is now posted online and is free to watch. The conference itself had three tracks: CI/CD, Automated Security and Modern Infrastructure, including:

    • Application Secret Management with KMS – Andrey Utis of Capital One
    • Getting out of the Job Jungle with Jenkins – Damien Coraboeuf of Clear2Pay
    • Serverful Computing – Taking One for the Team – Paul Czarkowski of Blue Box Group

    One of the best ways to learn about DevOps is to hear from the experiences of others who have run the gauntlet. Take 30 minutes this morning, at lunch or at home this evening to watch your first online session with All Day DevOps On-Demand.

    — Derek E. Weeks