Category: Events

5 DevOps Success Factors Surfacing At DOES 15

Two days into a breakneck schedule of energizing presentations at DevOps Enterprise Summit 2015 (DOES 2015) and there are already some common themes bubbling up from the speakers and attendees. As IT practitioners from big name enterprises like Capital One, HP, Target, Ticketmaster and more step up to the podium to share their personal stories about the journey to continuous delivery, they’ve proven that their transformations rely on similar success factors.

Success Factor: DevOps Champions

DevOps change agents and champions are the engine that can help turn an enterprise IT ship around. And while it will eventually take a lot of people to power a large organization’s shift to DevOps, the passion and vision of a single DevOps change agent is contagious—particularly when they can demonstrate and document the results of new process patterns.

“One person can make a difference,” says Sherry Chang, chief architect of DevOps and continuous delivery with Intel, who says when she first started helping her firm in its transformation, she had no formal DevOps title or role, but she believed strongly that changes needed to be made and was determined to drive them. She says she connected with others to start small and spread the DevOps gospel.

Success Factor: The Yin/Yang of Grassroots/Executive Support

Building DevOps momentum can’t depend solely on support from the bottom up or the top down. Those experienced in walking the DevOps path say that buy-in must come from both sides of the coin to truly transform the business.

Most transformations tend to start at the grassroots level—that’s what those champions are especially good for kick starting—because risk-averse executives tend to like to grab onto new initiatives that already look like potential winners.

“Those change agents are important in the early days because they can demonstrate success, which then helps to start growing a grassroots movement, where more and more passionate folks start to get bought into the different changes that are being talked about, and then that got us to gain our tops-down buy-in,” says Heather Mickman, director at Target.

Success Factor: Internal DevOps Events

Many of the biggest enterprises that shared their stories explained that a key component of the culture shift at their organization has been some sort of large-scale internal event—essentially in-house DevOps conferences. These events give DevOps champions the chance to bring in outside thought leaders and practitioners at other companies to demonstrate to people within the host enterprise that there really is something to DevOps, automation, continuous delivery and the like. For example, CapitalOne recently hosted more than 1,200 software engineers for an in-house event it calls SECon and brought in many of the same speakers we’re seeing this week at DOES.

Target has also hosted numerous internal DevOps days, as well as an executive summit that Ross Clanton, senior group manager at Target, called a “tipping point” for gaining top down support from executives.

Success Factor: Empowerment

Giving staff the tools the need to do their job and then getting out of the way to actually let them do it has been another common theme weaving its way through DOES talks.

“Teams crave responsibility,” says Jody Mulkey, CTO at Ticketmaster. “Folks on our development teams, they all want responsibility to run their products. They didn’t all want it in the beginning, to be quite honest. But once they saw how quickly teams were able to deliver and how they were able to minimize these business disruptions based on the ability to quickly make changes to their software, it was pretty incredible.”

He says of the 73 development teams at Ticketmaster in North America, 100 percent push their own code.

Success Factor: Test Automation

Time and time again, presenters have called out the importance of test automation in eliminating waste and idle time in the development lifecycle and elevating the process. On Monday, there was a whole panel dedicated to the topic with representatives from Intel, Quicken Loans and Bluware talking about how to scale this across the enterprise. And as Paul Schmid explained in his description of the DevOps transformation at Sherwin-Williams, like many organizations, his has been learning the hard way that test automation ideally should be one of the first steps to shifting gears to continuous delivery.

“Tests for us are really important, and we are not mature in this at all. So a lot of what was talked about this morning hit right at home,” he says. “Testing is really important and it’s definitely the next step for us, and we’re putting a lot of time, effort, and money into it.”

October 21, 2015
Live blogging DOES 2015

We will be live blogging from DOES 2015. Ericka Chickowski and Alan Shimel are live at the show in case you can’t be here yourself.

October 19, 2015
DevOps Chat: IBM draws on deep DevOps experience to launch Bluemix Garage Method

With the start of the DevOps Enterprise Summit 2015 this morning IBM has made what they are touting as a major announcement. Drawing on their wide and deep experience in DevOps across multiple segments of the company, they have announced Garage Method. What exactly is Bluemix Garage Method? Great question. I spoke today with Randy Newell, Director, DevOps Marketing at IBM about this. Below is a streaming audio of our conversation, followed by the transcript. I expect to follow up with Randy and other IBM folks this week on both DOES and Bluemix Garage Method, so look for a follow up shortly.

[soundcloud url=”https://api.soundcloud.com/tracks/228889575?secret_token=s-uhTmi” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

Alan Shimel:                Hi, this is Alan Shimel of devopsy.kinsta.cloud and we are kicking off our coverage of the DevOps Enterprise 2015 Summit in San Francisco. And happy to be joined by Randy Newell of IBM. Randy, welcome to DOES 2015.

Randy Newell:             Hey, Alan. Thanks. It’s great to be here. This is exciting.

Alan Shimel:                Yep, there’s a lot of buzz going around, Randy. A lot of companies announcing exciting news around the event. And I think I’ve heard IBM has some announcements coming out.

Randy Newell:             We do. We are announcing today a set of practices designed to help enterprise organizations execute and scale innovation. It’s called IBM Bluemix Garage Method and it combines the best of design thinking, Lean Startup, agile development, DevOps and Cloud, and is specifically designed to help enterprise organizations accelerate all phases of the app design, development and delivery lifecycle.

Alan Shimel:                Very exciting. So Randy, for our audience who may not be familiar, let’s start with the basics. Bluemix Garage – it sounds like a startup, what exactly is Bluemix Garage?

Randy Newell:            So Bluemix Garage is actually a set of physical locations that IBM has opened around the world — including in San Francisco, located in the Galvanize facility, where IBM brings clients and provides a startup type of environment. It’s really designed to bring in enterprise clients and take them through a methodology, a process, by which they go from ideation right through to delivered application in an MVP-type of situation, and really learn how to accelerate innovation. And this has worked extremely well. Where the challenge has come is how do I take that success and bring it back to my enterprise? Especially since many of these organizations are building innovation centers, lofts, etc. How do I capture that culture, that startup mentality that happened back in the Garage and scale it? And that’s what’s behind the Bluemix Garage method. So we’ve specifically named it Garage to capture that startup culture that we are cultivating within the Garage environment, and put a lot of that into the methodology and the way that people interact with it.

Alan Shimel:                Excellent, excellent. So Randy, I’ve been lucky enough to attend other few DevOps-related events recently, and I’ve seen that as a theme from IBM, this concept of how do we bring that startup energy, that startup methodology and sort of grafted onto the enterprise tree. And this announcement today kind of sounds like maybe the culmination of that.

Randy Newell:             It is. IBM has gone through a major transformation that reaches back almost a decade – but a lot of activity over the past couple of years where we’ve rolled out DevOps transformation within IBM to thousands of developers. And then of course, we are actually delivering DevOps transformation capabilities with clients, both at Bluemix Garages as well as through various services organizations within IBM. And so what we’ve done is taken the best of from those various methodologies and integrated that into what we’ve now named Bluemix Garage Method.

Alan Shimel:                Got it. Now Randy, I think one of the special sauces that IBM brings to an announcement like this is the breadth of services and people that IBM brings to bear on this. Can you give me an idea of how the different segments if you will or the different parts of IBM are coming together on this into one cohesive strategy and offering?

Randy Newell:             Well, it’s what I’ve defined as the input to this process. So you have the genesis within IBM from internal organizations, the CIO office, across different parts of Cloud and Software groups; and then of course what’s come in from what we refer to as Global Business Services. So all these have played a role. And obviously best practices coming from interaction with clients and with different business partners, as well.

The method itself consists of a digital experience. So it is a site that you visit and on that site is a practice library of work product assets, of shared learning in the form of videos and case studies and blogs. It’s an open community where clients, business partners, IBMers and third-party tool vendors will continue to progress and advance this methodology.

And then kind of an interesting perspective are these prescriptive adoption paths for various use cases so you can engage with the method in a role context or in a particular use case context. Let’s say I’m building a cloud native mobile app, you basically have that as a track or adoption path through the methodology.

So we are starting off — this is delivery of version 1.0. It will progress extremely rapidly so we’ll see new tracks for these prescriptive adoption paths added on a regular basis. We are pretty excited about that and it’s a really high-value add with the methodology.

Alan Shimel:                Fantastic. Randy, for people who may be listening to this or reading it while they’re out in San Francisco this week for DOES, any IBM sessions that will be talking about this?

Randy Newell:             Absolutely. In addition to the IBM booth where we will be demonstrating the Garage Method there are a couple of key sessions that I would suggest people attend.

Specifically, Tuesday, tomorrow, there’s a session with Angel Diaz, Rachel Reinitz and one of our business partners, Kristal York from PointSource, will all be talking more deeply about the Method. We will also be talking about it at an event called Night at the Garage on Monday evening, tonight, starting at 7:00 PM after the networking session is completed here at DevOps Enterprise Summit. This is an invitation to all DevOps Enterprise Summit attendees to get on a trolley with us and head 7/10 of a mile down the street from the hotel to Galvanize which is where the IBM Bluemix Garage is located in San Francisco, and join us for some demo stations where they can see more on the Method but also enjoy the bar, entertainment, and dinner. So that’s an invitation; we’d love to see everyone from DevOps Enterprise Summit join us.

So a little bit of a plug, later this morning, Dibbe Edwards is co-presenting with USAA on DevOps Innovation. Rosalind Radcliffe is presenting on Wednesday on test automation for mainframe applications. And then our Services Line leader for North America, Mustafa Kapadia, is driving a session on differences between traditional and DevOps IT.

Alan Shimel:                Sure.

Randy Newell:             So there’s a lot of neat sessions and we’d love to see people of course join us in the booth as well. We can show off IBM Bluemix which is our PaaS platform; IBM UrbanCode for deployment automation and DevOps Services capabilities that are integrated into IBM Bluemix. So lots going on within the booth in addition to the methodology that we are introducing.

Alan Shimel:                Fantastic. I’ve actually either interviewed or met many of the people you’re speaking about and they are all good presenters. So they should be good shows. Randy, what else? There’s a lot besides IBM going on at DOES. Non-IBM related, is there one particular thing that you are looking forward to?

Randy Newell:             I think back to last year’s event and Gene Kim set such a great tone, very collaborative; we saw otherwise competitors in the marketplace sitting together and talking about DevOps strategies. That was a great tone that seems to be persisting already at the conference this year. The conference was populated with a lot of sessions about initial successes within large enterprise. People telling their DevOps journey, initial successes. And if you remember at the time, one of the business reporters had written an article questioning whether DevOps could be applied to large enterprise. And here we are a year later and that question actually seems pretty comical now. So I think the observation, and I see Gene evolving the sessions to be this way, it’s about the “how”, right? So it’s not the proof points of DevOps so much anymore that it works and it delivers value — whether that’s measured as speed, improved quality or reduced risk. But that DevOps success is directly related to business outcomes and how you scale those successes at an enterprise level. So kind of bringing it back, this is timely for the introduction of the methodology that I described earlier.

Alan Shimel:                Absolutely. So Randy Newell, it sounds like IBM is on top of their game here at DOES. And a lot of exciting announcements and you guys are really integrated into this whole DevOps party going on here if you will, and how we continue to evolve to the next phases of DevOps adoption. Thanks very much for checking in with us today. Enjoy DOES and will check back with you maybe at the end of the show and get some thoughts.

Randy Newell:             Okay, great. Thank you very much, Alan.

URL: IBM Bluemix Garage Method – www.ibm.com/devops/method

October 19, 2015
Webinar: Starting a DevOps & Continuous Delivery Transformation in the Enterprise
Faster delivery of software that better meets the needs of your customers. The story is compelling in theory – the real challenge enterprises are facing is how to get started.

Find out how on November 17th. Bring your questions to an interactive panel with the experts and they will field them live.

Gary Gruver and Tommy Mouser, authors of Leading the Transformation: Applying Agile and DevOps Principles at Scale and Andrew Phillips, VP, Product Management for XebiaLabs and co-author of the IT Manager’s Guide to Continuous Delivery, will draw on their experience implementing Continuous Delivery transformations at major organizations to prepare you for how to plan and what to expect as you start your journey to DevOps and Continuous Delivery.

Some questions that will be covered:
- What are the essentials for preparing for your transformation?
- What are the most common business objectives and crucial first steps?
- How can you scale Continuous Delivery for the Enterprise?
- What are the key measurements along the way?
Bonus: Register and attend the webinar to receive the first two chapters the new book:Leading the Transformation: Applying Agile and DevOps Principles at Scale. Make sure to submit your questions upon registration – we’ll be giving away free copies of the entire book to the registrants with the most interesting questions!

Date: Tuesday, November 17th, 2015

Time: 11:00 am eastern standard time

REGISTRATION LINK: (CLICK HERE)

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Tommy Mouser, Co-Author, “Leading the Transformation”

Tommy Mouser has been directly involved in the design, development, qualification, and delivery of software systems for over 30 years. For the past 8 years, while working at HP and Macy’s.com, his primary focus has been on working with his teams and partners on a journey towards Agile methodologies. He has led, managed, and applied these principles with many teams, both large and small, and has experienced the significant quality and productivity gains that are possible.

Gary Gruver, Co-Author, “Leading the Transformation”

Gary Gruver is currently working with Executives across the industry to help them transform their development and delivery processes. As Co-author of “Leading the Transformation” he shows executives of large traditional organizations how to lead their transformation by applying Agile and DevOps principles at scale. As co-author of “A Practical Approach to Large-Scale Agile Development” he documents how they revolutionized software development processes at HP while he was the Director of the LaserJet Firmware development lab.

Andrew Phillips, VP of Products, XebiaLabs

Andrew is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. In his spare time Andrew contributes to a number of open source projects, including Apache jclouds, the leading cloud library.
October 12, 2015
Webinar: Testing Infrastructure as Code with Security: 5 Practical Tips
Testing is one of the core parts of infrastructure as code. However, when thinking of testing, what role does security play?

In this informative webinar, we will discuss:
- Security’s role in testing
- Guidelines for doing active testing while incorporating sound security principles
- 5 security considerations for testing implementations of infrastructure
Date: Tuesday, November 10th, 2015

Time: 1:00 pm eastern standard time

REGISTRATION LINK: (CLICK HERE)

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Jamesha Fisher, System Administrator DevOps at CloudPassage, Inc.

Jamesha Fisher is a CloudPassage systems administrator working on DevOps. She has gained her technical knowledge from working in systems administration and technology roles at companies such as Google, GoGrid, and Norvax, Inc. With a wide range of technical experience in security, networking, and information systems, Jamesha has the knowledge and expertise to back her up as a leading professional within the DevOpsSec community.
October 7, 2015
Webinar: Scaling Jenkins with Docker and Kubernetes

Docker is revolutionizing the way people think about applications and deployments. It provides a simple way to run and distribute Linux containers for a variety of use cases, from lightweight virtual machines to complex distributed micro-services architectures. Kubernetes is an open source project to manage a cluster of Linux containers as a single system, managing and running Docker containers across multiple Docker hosts, offering co-location of containers, service discovery and replication control. It was started by Google and now it is supported by Microsoft, RedHat, IBM and Docker Inc amongst others. Jenkins Continuous Integration environment can be dynamically scaled by using the Kubernetes and Docker plugins, using containers to run slaves and jobs, and also isolate job execution.

Recording

Slides

[seoslides embed_id=”8ade4e25d29a” script_src=”https://devopsy.kinsta.cloud/embed-script/cloudbees-scaling-jenkins/10902/” overview_src=”https://devopsy.kinsta.cloud/slides/cloudbees-scaling-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”CloudBees, Scaling Jenkins” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Carlos Sanchez Gonzalez,Senior Software Engineer, CloudBees

Carlos Sanchez specializes in the automation and quality of software development, and QA and operations processes, from build tools to Continuous Delivery following the DevOps philosophy. He has spoken on the subject at several conferences around the world. Involved in Open Source for over ten years, he is a member of the Apache Software Foundation amongst other open source groups, contributing to several projects, such as Apache Maven, Fog, or Puppet. He works at CloudBees scaling the Jenkins platform.

September 25, 2015
Webinar: The Modern Office: How Google Apps Solves the IT Identity Crisis
Google Apps has completely infiltrated workflows, enabling teams to work together seamlessly, from anywhere. But throw in Macs, SaaS-based apps, and cloud infrastructure, and IT has a bit of an ‘identity crisis’: their work is all over the cloud, but their directory service (generally Microsoft AD) is firmly rooted on-premises.

Companies are beginning to ask if they can just use Google Apps as the identity store at the core of their business. In the modern office, you can. As of 2015, Google Apps now has the capability to be a complete identity solution – and it will simplify your IT work life in a truly futuristic way.

Join JumpCloud’s Chief Product Officer, Greg Keller, and Bitium’s Chief Technical Officer, Erik Gustavson, as they discuss optimizing your business using Google Apps in these five core areas:
- Security and Compliance
- SSO
- Devices and Servers
- Wifi
- Directory Services
Recording

Slides

[seoslides embed_id=”1ca5ca5783ff” script_src=”https://devopsy.kinsta.cloud/embed-script/the-modern-office/10214/” overview_src=”https://devopsy.kinsta.cloud/slides/the-modern-office/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”the-modern-office” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Greg Keller, JumpCloud, Chief Product Officer,

Greg is JumpCloud’s Chief Product Officer, overseeing the product management team, product vision and go-to-market execution for the company’s Directory-as-a-Service offering.

Erik Gustavson ,Bitium, Chief Technical Officer

As Bitium’s co-founder and CTO, Erik establishes the technical and product vision, guides product development activities and oversees the engineering organization.
September 9, 2015

Webinar: Evolving the Jenkins UI

Jenkins is the clear #1 continuous integration (CI) and continuous delivery (CD) tool because it is very effective when it comes to automated testing and deployment of software in complex and diverse environments. Jenkins has achieved this position in spite of the fact that it doesn’t look as “trendy” as some of the other tools available in the CI/CD space.

In this talk, Gus will detail ongoing efforts to evolve the Jenkins UI. The goal of the initiative is to give Jenkins a more modern look and feel. They’ll talk about the challenges inherent in this effort, as well as some new Jenkins UI building tools and patterns being experimented with at CloudBees.

People interested in the Jenkins UI should attend this talk. Please bring your bag of ideas and get involved with this effort.

Recording

Slides

[seoslides embed_id=”69f217917af8″ script_src=”https://devopsy.kinsta.cloud/embed-script/9828/9844/” overview_src=”https://devopsy.kinsta.cloud/slides/9828/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=” ” /]

Q&A Follow Up

How likely is it that any of these UI changes will make it into the core open source Jenkins? When would we start seeing them there?
Most will be OSS. An exact schedule has not been determined, but most of it is still about a year away. Likely we will have an experimental wars for download along the way.

Is there anyway to determine which GUI attributes are contributed by which plugin
I take it that is a bit of a feature request? It came up at JUC West as well. Should be something that can be surfaced in the GUI. I agree, it would be helpful.

What is the difference between ANT and Jenkins?
Ant is a good bit more bare-bones than Jenkins. In fact, you can add an Ant plugin to your Jenkins environment. You would typically use Ant to compile java source files. Jenkins orchestrates the fetching of the source files from some particular repository, the building of those files (often Jenkins uses Ant via its plugin to do this), running and reporting some suite of tests against that build, and then archiving or deploying the artifacts to wherever. Often times this requires navigating several computers with their own security constraints, so Jenkins helps you manage that as well.

What version of the Jenkins it is?
This isn’t available today, but I am building against 1.621-SNAPSHOT currently, but will upgrade with Jenkins to the coming December LTS.

I’m interested in seeing the list of 100 plugins that you mentioned (by Daniel?)
Me too. :^) He and the community (which can be you if want to join IRC freenode.net/#jenkins and attend the hangouts and governance meetings: http://jenkins.ci.org )

For IRC, I assume the server is freenode.net?
Yes.

Will there be any dashboard kind of feature for the build history in the new GUI
So far, I have been focusing on the create and configuration portion of the Jenkins UX as I see it as a barrier to entry for new users. The read/report/analyze half of the Jenkins UX I actually see as the portion with more long term value, as you tend to read more often than you write, so I am eager to jump in here as well.
….however, in its core today, Jenkins the tool seems to me to really want to see the world in the same context of flat XML files in folders as it actually persists its configuration data. To really make meaningful dashboards, it needs to be possible to query job configurations and build artifacts by a wide set of criteria that is not at all related to the folder in which the xml file happens to be stored. Also, some of the things you care about in the Jenkins universe are compute resources (masters/slaves/exactures). These are also not the same as config files in folders and need to be queryable as their own first class type of entity.

…so what I am saying with a lot of words is that I see the config piece as a somewhat more immediate and urgent fix. The broccoli of the meal, if you will. I will want to get that out as fast as possible to get it out of the way. The reporting piece is actually the wine. At the moment, we are giving you Bartles and Jaymes in paper cups.

…so a lot of work is still needed there.

Have you investigated Google Polymer as UI components for jenkins UI?
I have not, but will now. I am actually quite a google fan-boy in much the way a lot of kids love Apple. (I also love Apple… being from Seattle, I even love MS). But, for the super near term, we are most focused on getting JQuery cleanly into core and Prototype.JS deprecated. Walk first, is my feeling.

Are there any tutorials on Jenkins workflow?
Jesse Glick or KK are better people to ask about that, really. They are also on IRC: freenode.net/#jenkins. Daniel Beck as well, might be a good person to ask. My little workflow demo is still really just fiction.

Will there be a ‘Expand All’ and ‘Collapse All’ buttons for the accordions in new configure GUI? (I would probably inject one if not by default)
Yes. Also, they should be URL controllable so that they can be set by link or user context easily. Maybe they should also remember what you had open last? …stuff to tinker with that really needs to be right.

What impact does the UI changes have on job configuration behind the scenes? Is configuration still stored in XML format?
None. The post string stays the same and from then on, Jenkins is Jenkins.

Can the create item screen be configurable?
At the moment, no, but ideally yes. It is still a big hand wave at the moment about how those categories are created, managed, and updated. The same categories ought to bubble back up when searching for the plugins to help relate what plugins generate what UI. I am hoping for guidance from the community.

How will workflow fit in with new UI?
In some respects, the new configuration page is about enhancing the more traditional freestyle job and not workflow. However, the last bit of my presentation with the script builder is exclusively about workflow. The plugin manager is about plugins, so it would apply to both.

How is a human notified for the wait for approval step in this workflow?
So workflow approval can be done via the web GUI. But to get real notification, you would program that into your workflow Jenkins has a fairly large set of notification plugins. So you can use Jenkins to trigger email, or SMS, or HipChat, or Slack, or pretty much whatever. As these plugins are increasingly customized for workflow, you will get nice and nice workflow syntax for instantiating those actions. When my script builder is adopted, you would have a friendly button you could drag into the stage and it would notify you prior to the manual checkpoint.

Custom plugins still supported?
Yes. Though there is supported and supported. The highest level of support for a plugin would be a custom DSL for workflow that would make for streamlined syntax in workflow for interacting with that plugin via Groovy. But existing plugins do not need that level of support to be used within a Jenkins file / Groovy script. Instead, the syntax for accessing the plugin is likely to be more complicated.
….some plugins are freestyle specific, in which case, they no longer make sense in workflow.
….Daniel Beck or Jesse Glick are probably better suited to answering this question, however…

Will there be an improvement in performance with docker builds, sonar scanning? From my experience sonar takes 20+ mins with jenkins plugin where as it takes 3 mins with maven plugin
Is this times it is taking the GUI to render, or the actual build to run? I am not sure I am following the question exactly, but regardless, I am not well equipped to answer many questions about performance issues in Jenkins. I know of a fairly major performance issue specifically in the configuration form that I believe will be fixed in the new GUI, but that isn’t build performance, it is just form rendering performance.

I like the graphical configuration. Thanks. The scripting of a complex workflow looked a bit daunting.
Cool. Yeah, my main and first goal is to get something out there that would allow folks to quickly sketch and deploy an actual working workflow that reasonably reflects an 80%ish use case. No GUI can ever be as fully flexible as a script, but I don’t think most people need the 95% case to get started and see the benefit of a versionable and robust config file format.

Will there be any effort to make the UI mobile friendly for the admin on the go?
Absolutely. Especially on the TBD read/reporting end of the UI, but everything new needs to meet a reasonably high bar of device responsiveness. Today, the Jenkins GUI is just not responsive. Which is terrible.

As a plugin developer do I need to change implementing the ui source from jelly or groovy to some other language/technique or will it be compatible?
So you will not NEED to change from whatever you are doing, except if you have built a plugin GUI that has custom script that either relies directly on behavior.js, hudson-behavior.js, or the particulars of the existing DOM structure (you do something in the client that requires your or some other input to be in a particular <table><tr><td> DOM traversal path).
…I believe 2 things are going to continue to happen at a faster and faster rate. New plugin authors are not going to want to write GUIs in Jelly and Prototype.js, but instead use some more modern client side MVC approaches like Angular, where the GUI interacts with a REST api instead of being a dom directly rendered from the server. It is a bit of a different mode of working than Jelly, and maybe slightly less direct, but it is a lot easier to find doc on how to do things with JQuery, Agile, Handlebars and the like, than it is to find doc on Jelly. And the responsiveness and breadth of gestures and controls in Jelly are already terribly behind what is now the main stream of web UI development. So I think plugin builders are, if they aren’t already, going to want better tools available to them.
I also think that people are going to gravitate towards workflow or something similar. Since the UI for workflow is foremost a script, making a GUI for a plugin that works with it might be a fundamentally different beast. …depending on what the plugin is trying to do… So again, new plugins or even upgrading existing plugins to work with workflow are likely want a new technology set, not just because the existing Jenkins GUI is changing, but because new plugins will want to do different and better stuff.

Are there connectors for other source control tools like CVS and Dimensions?
I am not sure exactly which connector plugins are already supporting Workflow or how deeply that support goes. Because Jenkins has plugins that provide access to these SCMs, you can use workflow to go and fetch those source trees. A greater level of support for workflow from these plugins would mean a more elegant workflow syntax for that interaction. At the moment, my GUI script builder is still fiction. My plan would be to add GUI buttons for whatever are the most popular SCMs and I will attempt to mask the syntax regardless of its clumsiness.
….the way I am constructing my initial prototype, there is already a reasonably clear extension point for adding buttons that generate some chunk of Groovy syntax when it is dragged into a stage. So I will add the initial set based on community feedback and then the community can continue to add their own.

What are the compatibility issues existing plugin developers needs to be aware of?
For plugins that interact with freestyle jobs, or really most job types that aren’t workflow, plugin developers should expect the page DOM structure to change. If for whatever reason, they find they are busting into some custom script to traverse the DOM to compare 1 setting to another, that will break.
Also, hudson-behaviors.js itself has a number of functions in it that do DOM traversing, like “findFollowingTR”. In some cases the signatures of those functions might need to change and the DOM structure that they return might also change. If a plugin uses what were meant to have been internal functions, they are likely to break.
Finally, the page geometry is going to change. This may seem so superficial and obvious that, who cares, but sometimes changing a column width translates into an important part of a GUI being hidden or otherwise inaccessible. That ends up being as critical a break as any other.

…so to combat these points of possible breakage, we are going to be looking for a handful somewhere between 20 and 100 plugins that we will want to test against. We haven’t made that list yet, let alone run any tests, so that is really a critical next step.

For the plugin manager changes, I don’t see much if any of a braking issue, although I would like to add additional sorting and display power to the GUI, which means the GUI will need more metadata than currently exists, if the plugins want to take advantage of that new power in the GUI. This won’t break things, but plugin authors might want to go back to their plugins and fill in whatever the new bits of metadata end up being…. most likely they would be things like, richer descriptions, better category selections, and possibly icons.

I’ve not seen a lot of Jenkins but what I had I didn’t really get, was awkward for all the reasons Gus mentioned. This looks brilliant. When can we have it?
Tom and I, and now our junior pledge, Keith (not actually junior at all, just more fit than me), are busily typing as fast as we can as well as lobbying the community that our vision is more or less a correct one. We have a very interesting initial plugin selection GUI that might make this years final LTS (which I did not demo), which is none-the-less a nice step forward for Jenkins. In it will be a lot of the JS library bundling that will enable most of what I have shown in this demo. Our hope is that with each LTS we will be able to push out an additional piece of the GUI puzzle. Likely starting with the job create and configure GUI, which would be the mid year LTS. I am hoping that a year from now this will be how Jenkins looks and acts.
….in the meantime, we are grappling with how best to push preview releases so people can play with it and send me hate mail.

Is there any way to test front end of Jenkins plugins? And will that improve too?
A major and almost blocking portion of this work used to be the custom and somewhat broken version of HTMLUnit that was in core, which greatly hampered including libraries other than Prototype in Jenkins and writing code using those libraries in some sort of testable way. Our new approach to rebuilding the Jelly controls which are the foundation of the Jenkins config page and in general are shared by all plugins that need to post data back to Jenkins, already have a testing strategy backed into our design. Those Jelly form controls are extensible in Jenkins today and would remain so. Our hope would be that any plugin adding custom controls would follow our same design and test pattern we are building in core.
….so that was a long answer, but the short answer YES! Today, building GUI parts into your Jenkins plugin is a bit of a mystery, where most people copy something they saw someone else did, hack it, and the only test is, well…. it worked for me. That is no good and a fundamental piece we are looking to change.
….still a long answer…
Node.js and Jasmine are the specific tools we using.

What’s the estimated rollout date for this workflow feature?
The workflow feature is the newest concept I demonstrated, but in a lot of ways may also be the easiest to ship. As a script generator, exclusively, it could be hosted anywhere, and then you just paste your generated workflow script into the whatever existing Jenkins GUI better, submit into your source code.

….but at the moment, it isn’t actually on an official roadmap yet.
Assuming the response to it remain positive, I would expect that to change fairly quickly.

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Gus Reiber, Senior UI Developer, CloudBees, Inc.

A blue eyed Capricorn, at 5’8, 190lbs (41-43-40), Gus is a power-puck of usability lovin’. With 20 years of design and UI/UX experience, Gus has mixed it up with companies large and small, including a large number of startups and first-release software products. Best known in that list are Allaire, Macromedia, Adobe, and Hitachi Data Systems. Now at CloudBees, Gus is looking to make friends with the CloudBees community and bring Jenkins into the next generation of user experience goodness. Ladies, form a queue…

September 9, 2015

Webinar: Leading the Transformation

Join us with Gary Gruver, Co-Author of “Leading the Transformation” and “A Practical Approach to Large-Scale Agile Development”, for an in-depth look at transforming software development processes in large organizations.

The book and presentation focus on showing executives how to lead the transformation of Enterprise scale software development processes. Instead of the traditional Agile and DevOps approaches that focus on improving the effectiveness of teams, this book targets the biggest inefficiencies in most large organizations that executives are uniquely positioned to address, which is coordinating the work across teams.

Recording

Slides

[seoslides embed_id=”a058eb467149″ script_src=”https://devopsy.kinsta.cloud/embed-script/9558/9588/” overview_src=”https://devopsy.kinsta.cloud/slides/9558/” title=”” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Gary Gruver, President at Practical Large Scale Agile

Gary Gruver is an experienced executive with a proven track record of transforming software development and delivery processes in large organizations. He is currently working with Executives across the industry to help them transform their development and delivery processes. As Co-author of “Leading the Transformation” he shows executives of large traditional organizations how to lead their transformation by applying Agile and DevOps principles at scale. As co-author of “A Practical Approach to Large-Scale Agile Development” he documents how they revolutionized software development processes at HP while he was the Director of the LaserJet Firmware development lab. As VP of QE, Release and Operations at Macy’s.com he led their transition to continuous delivery.

September 4, 2015
Webinar: Enabling DevOps and Containers on VMware with Nirmata

Application container technologies such as Docker are being increasingly adopted by developers to accelerate application development. But as IT teams look to support containers across multiple development teams, and across clouds, they are faced with daunting challenges and complexities of building and operating new tooling for each infrastructure and cloud provider.

In this webinar you will learn how Nirmata can ease the adoption of application containers for enterprises, and help automate the deployment, operation, and optimization of containerized applications. The discussion will include a real-world case study of how VMware’s Enterprise IT application team rapidly enabled the best of both worlds – DevOps agility for developers without any additional complexities, using VMware infrastructure solutions, vCloud Air, and Nirmata.

Join Jim Bugwadia, Founder and CEO of Nirmata; Paco Gomez, Senior Solution Architect for vCloud Air; and Thirupati Panyala, Director of Enterprise IT Applications, for an in-depth look at the key challenges involved with container technologies and how you can enable a DevOps transition for your organizations without any compromises.

Recording

Slides

[seoslides embed_id=”9c6d176d5993″ script_src=”https://devopsy.kinsta.cloud/embed-script/9912/9980/” overview_src=”https://devopsy.kinsta.cloud/slides/9912/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=” ” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Paco Gomez, Senior Solution Architect, VMware

Paco evaluates and integrates strategic solutions that help vCloud Air clients benefit from VMware’s hybrid cloud and application services. Paco is a seasoned technologist, having extensive experience in diverse fields including mainframes, distributed systems, enterprise development, cloud computing, mobile, assistive technology, electrical engineering and embedded systems. Across his career, Paco has held positions in consulting, sales engineering, product development and as an entrepreneur.

Thirupati Panyala, Director of Enterprise IT, VMware

Thirupati is a Director of Enterprise IT Applications and Platforms at VMware, responsible for custom apps and mobile solutions group. Mr. Panyala is focused on strategizing the continuous delivery through infrastructure transformation and developing a DevOps culture in improving the speed, agility, quality and predictability of enterprise apps delivery.

Jim Bugwadia, Founder & CEO, Nirmata

Jim started his career developing large-scale distributed software at Motorola for cellular network infrastructure, where his team launched the world’s first CDMA network. Since then Jim has held several developer, architect, and leadership roles at companies like Bell Labs, Cisco, Trapeze Networks, and Pano Logic and others. In 2013 Jim founded Nirmata, a startup focused on solving Enterprise DevOps pain points, by providing multi-cloud management of Microservices style applications that are deployed using containers.

August 31, 2015