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:
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.
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.
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…
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.
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.
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.
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.
Today’s enterprise applications require extreme database performance and scale to keep up with growing business and user demands.
In the past, scaling your database meant adding more nodes to your clusters, regardless of what services those clusters powered. Now, with features like multi-dimensional scaling, enterprises can optimize their database infrastructure with unparalleled precision to power the next generation of business applications.
Join Shane Johnson, Sr. Product Marketing Manager at Couchbase, as he discusses the shift to next-generation enterprise applications and how NoSQL databases like Couchbase power them.
Topics include:
How a shifting business model is fueling the need for next-gen apps
The important characteristics that make these new apps different
Strategies for funding, building, and succeeding with your company’s next-gen apps
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.
Shane Johnson is the Manager of Product Marketing at Couchbase. Prior to Couchbase, he occupied various roles in developing and evangelism with a background in Java and distributed systems. He has consulted with organizations in the financial, retail, telecommunications, and media industries to draft and implement architectures that relied on distributed systems for data and analysis.
In this webinar we’ll discuss the basics of SSH authentication – passwords, keys, and MFA, oh my! We’ll also investigate some common patterns of key propagation — how do you get your users’ keys onto the appropriate machines — including:
* Manual distribution
* LDAP
* Puppet/Chef configuration
* Advanced techniques
We’ll also highlight the different challenges involved when doing this against different IaaS vendors (AWS and GCE), in a locally-hosted environment, and in the hybrid of the two.
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
Topher Marie, CTO of JumpCloud
Topher is the CTO and Co-Founder of JumpCloud. Previously he spent five years at Symplified as its lead engineer holding a variety of titles including Architect and Development Manager. The bulk of his time was spent wrestling with the concepts and mechanisms of provable identity – SAML, IWA/Kerberos, PKI, OAuth, OpenID, and multi-factor authentication to name a few. Topher holds Bachelor and Master of Science degrees from the Colorado School of Mines in the area of Math with emphasis in Computer Science. He also spent several subsequent years at that university as a part-time professor for both computer science and pure math courses.
The concepts of communication, collaboration, abstraction, automation and orchestration are cornerstones of the rapidly growing DevOps movement. At the same time, reliance on elastic infrastructure has exploded, making manual security provisioning and management infeasible. Applying security policies based on static parameters and making manual rule changes just before production leaves little time for provisioning the policies. This impacts release quality, increases risk of errors and slows down the DevOps cycle. Now security teams have an opportunity to learn from the DevOps experience.
Attend this informative webinar to learn:
Common pitfalls associated with using traditional security solutions in DevOps environments
Key ingredients to look for in a security solution that matches the speed of DevOps
Real-life case studies of companies who have adopted DevOps methods to security
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.
Amrit Williams has more than 20 years of experience in information technology and is currently the CTO of CloudPassage. Previously Amrit was the Director of Emerging Security Technologies and CTO for mobile computing at IBM. Prior to IBM, Amrit was a research director in the Information Security and Risk Research Practice at Gartner, Inc. where he covered vulnerability and threat management, network security, security information and event management, risk management, and secure application development. Previously, Amrit was a director of engineering for nCircle Network Security, and undertook leadership positions at Consilient Inc., Network Associates, and McAfee Associates.
Continuous delivery (CD) of applications is rapidly becoming a differentiator in this application economy. CloudBees, the enterprise Jenkins company, recently announced the availability of the CloudBees Jenkins Platform to help organizations adopt CD. This new enterprise offering from CloudBees brings CD to the masses with the new Team Edition, while enabling enterprise CD deployments powered by Jenkins at scale with the Enterprise Edition. At the same time, the Jenkins open source community, in conjunction with CloudBees, released six new plugins to support the use of Docker containers within Jenkins-powered CD and CI processes. Docker is powerful new technology that allows teams focused on delivering software to standardize their development and production application environments for reduced risk and accelerated application delivery. Leveraging Docker containers in a CD process managed by Jenkins is the ultimate way to deliver better software faster.
Join Tracy from CloudBees as she talks about Cloudbees’ new enterprise offering and the changes happening in the Jenkins community to provide first class support for Docker in the creation of CD pipelines. In this webinar, Tracy will introduce features in the latest release of the CloudBees Jenkins Platform to
help manage Jenkins’ across the organization and walk through six common delivery patterns with Jenkins and Docker. Tracy will then tie it all together with a demo of an end-to-end delivery pipeline with Docker.
Continuous delivery with Jenkins and application containerization with Docker are rapidly becoming two of the foundations of the DevOps movement. Check out this webinar to learn how you can adopt these new tools and techniques in your own DevOps transformation.
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
Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.
Udaypal Aarkoti is the Director of Solution Architecture at CloudBees. He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat.
In the application economy, you have to deliver software as if your business depends on it … because it does! It’s a bold statement, but true. Think of nearly every interaction a person might have today—be it for work, commerce or play. Most have a digital dimension, which relies on digital technology and platforms.
In order to survive and grow, every company needs to become a technology company and every business needs to become a digital business. Successful transformation requires Continuous Delivery, the new business imperative that enables you to rapidly develop and deliver applications that drive superior user experiences and engage your customers and staff.
But the traditional “software factory” or process for transforming an idea into a customer experience is throttled by a number of bottlenecks in the delivery pipeline. That means delivering innovative, high-quality applications, faster and more frequently can be a chaotic and complex process, particularly if your application delivery systems and processes were designed to only push out one or two releases a year.
Join moderator Alan Shimel, devopsy.kinsta.cloud; and experts Georg von Sperling, DevOps and Technology Evangelist at CA Technologies and Julie Craig, Research Director at Enterprise Management Associates (EMA) on July 21, 2015 to discuss ways to overcome today’s application economy challenges with solutions designed to transform your software delivery lifecycle into a continuous delivery pipeline of digital innovation.
Recorded: Tuesday, July 21, 2015
Recording
Q&A
1. Based on your experience tell me : continuous delivery versus traditional development. The continuous delivery model is perfect for every business ?
GvS: As a goal, yes, absolutely. Because continuous delivery practices enhance what is already being done and simply promote good behavior over creation of waste. Removing bottlenecks to increase quality, frequency and velocity simply makes sense, regardless of the business you are in. Now, that said, continuous delivery is not necessarily perfect for every business if you define it as continuously delivering to production. But what development organization would shun away from getting early and amplified feedback in User Acceptance Test (UAT)? To accomplish this, you still require every one of the concepts in continuous delivery.
ANBU: If you think of achieving Continuous delivery as a means to achieve modularity & lose-coupling in order to achieve higher workforce productivity, every business will be motivated to do it. As a concept, it is perfect for every business, but the objectives of the process and their order of their importance will vary industry to industry. As long as you make these adjustments, you will benefit a lot.
2. One of our struggles is the impact of Continuous Delivery on our Environment Strategy and the Mechanics used to maintain them. For example, applications dependent on other applications / components will require those other applications / components in the environment infrastructure in which testing is occurring. How do you see Compnay Environment Strategies changing to support Continuous Delivery? When does it become necessary to change an application’s architecture to reduce or remove these dependencies? Or are there testing methodologies that can accurately test changes without the need for large QA Environments?
GvS: The path with the least resistance is seemingly learned from the airplane manufacturing industry. When there is a new wing design that is required to undergo quality validation, the dependent systems and datasets are so complex, they could not have ever released those designs if they threw up planes into the air with different passenger or luggage loads (data) in different weather conditions (environment) attached to a full airplane body (dependencies). Likely, this would have resulted in the same adverse effects that we experience when pushing a digital asset from our IDE to the first environment – often catastrophic. Virtualizing dependent services with actual behavior – just like in a wind tunnel – is a good approach. This also allows discovery of the dependencies in consumable, shareable format which, should you find additional needs to revisit the architecture, actually aid in the process of redesign.
ANBU: I would recommend a model-based approach in your situation. In your stated example, if you model ‘infra-as-code’ and try to achieve modularity at that level, so that developers and testers call it out during their plan/design/development process to make their ‘availability and use’ defined, the problem can be solved. It requires an assessment on all the functional components (infra included) in order to model it. There are tools out there that would help you achieve such a modeling.
3. How do you measure the success of DevOps other than faster & quality releases? are there any metrics that can be collected periodically?
GvS: In the context of Continuous Delivery, there are many metrics that can and should be captured. Many more in the context of DevOps. We could likely devote an entire session on this. Let me focus, however, on continuous delivery metrics. On top of focusing on business-oriented outcomes, much like in DevOps, some operational metrics could be captured. Examples are:
– Lead time to production. Measuring cycle time from the work starts to the time the team’s definition of ‘done’.
– Defect resolution time. Really successful teams can fix defects as quickly as they are discovered. The more left-shifted the defect discovery is, the more quickly they are resolved.
– Production defect leakage. Measure both: new defects found and defects previously found and still made it to production.
– Defects. It is bad enough to ship buggy apps. Continuously doing so is even more terrible. Measure at each stage in the cycle, and notice a left-shift if CD is going well.
– Broken build time. The longer a build sits around broken, the commitment to quality is just not there.
– Production downtime during deployment. If you achieve zero-downtime, you can stop measuring here.
– Regression test duration. Teams with manual practices will measure in months or weeks. CD teams will likely measure in minutes or hours. Also include lead-time to regression test.
– Performance test outcomes. If you find tons of functional bugs in performance testing, there is likely a bottleneck not addressed early in the cycle.
– Touches. Number of tickets, emails or other communication required to do a deployment in each stage. If it isn’t “zero-touch”, there is improvement potential.
This is not a complete list, but certainly one to start with
ANBU: GVS’s response is complete.
4. How do you get legacy code/systems into the CD model? Or is CD only for new code/projects/systems?
GvS: The practices advocated with CD aren’t specific to the tenure of the project or the age of the technology. They are arguably all good practices and make perfect sense. Now, if you are an enterprise on the journey to adopt CD practices, the recommendation is certainly to begin with projects that have the highest business impact. A good heatmap analysis does go a long way to begin. If it turns out that it is your legacy code/system, so be it. Parallelize work streams, accelerate quality and automate & orchestrate the delivery pipe.
ANBU: Legacy code/systems are generally monolithic/tightly coupled. Hence the problem. Unfortunately, they are also part of the corporate string of applications, so we can’t stay away from them. We have seen examples where these systems stay as one ‘component/workstream’ and plug into the larger CD stream, creating a hybrid-model. Yes it is not perfect, but will help you implement CD. Additionally, the maintenance/re-engineering of these legacy systems are opportunities to change the code to adopt to the larger CD strategy that you put in place. If they are truly legacy, there won’t be major ‘patch’ work so they stay what they are.
5. How do you reconcile product management with CD, i.e., the definition of a story to encapsulate a deployable or atomic element that can be delivered? Often times stories are part of a larger epic that needs to be delivered as a whole and not on their own. so the issue is deploying atomic units/stories creates the fear of delivering partial functionality. How does a business deal with this and overcome this
GvS: If you pardon me, but it seems a misinterpretation of CD itself. Deployment and delivery are two, if not three, different things. I believe you may have latched onto the “live” deployment of an atomic change to production. Given the right strategy in modeling the pipeline itself, all CD elements are still valid, the atomic element may go “live” with many other atomic elements. BUT, unlike in the past, the fear of failure in that deployment is minimized as quality drastically improved and, the same, already tested, processes are utilized to set the atomic unit “live” as have been validated in lower environments. It is a journey.
ANBU: one of the benefits of CD is achieving the readiness of production deployment of (ALL or SELECT atomic units) on a push of a button. It does not force you (but you have the choice) to deploy every atomic unit into production If what you said “larger epic as a whole or none” is important, then your definition of the ‘select’ atomic units should correlate to it. Configuration mgt and release mgt should have proper ‘gates’ to make sure that they roll-out properly.
6. My question on metrics is because in legacy orgs it takes a lot more time & energy to get to CD, so measurement through metrics is critical.
GvS: Absolutely, metrics and measurement go hand-in-hand. Looking at CALMS (Culture, Automation, Lean, Measurement and Sharing) for guidance, influencing the organizational culture through measurement and sharing which both are derived from automation is the nirvana. Along with the will of the IT organization, there also has to be executive buy-in to the strategy. Yes, grass-roots is fine, but a lot can get accomplished if the company stands behind the strategy. Having defined positive business outcome metrics as part of that journey helps reinforce that postion.
ANBU: Agree with GVS.
7. What is the Quality as a result of continuous delivery? What is the tradeoff with respect to the Business impact to defect leakages in production?
GvS: Quality metrics should show drastic improvement if CD tenants are implemented. There was a question on metrics already. This is not about continuously deploying bad code, which really just makes things worse, but about continuously delivering, where quality is certainly a determining factor.
ANBU: You need to baseline ‘quality’ before and after CD. There is an absolutely no way, these measures should negatively trend, if you properly implement CD. Defect leakage in any model will have the same implications, just that in CD – the mean time to resolve (MTTR) these issues should be faster.
8. For a business to adopt a CD model, doesn’t all disciplines/functions have to change to suit the atomic delivery concepts.
GvS: Once nirvana is achieved, likely there was a change in all disciplines and functions. It is a journey that must begin. The imperative is there for the business. But, much discussed in the context of DevOps as well, CD is a journey of transformation – not something you do in a day.
ANBU: YES. this is a life-cycle process, hence the impact is for everybody. But you can start from one unit/organization and spread it out to evolve it. if you have the luxury, start a new project/unit with CD as the foundation.
9. How do you see ITIL and DevOps interacting to maximize the benefits of continues delivery?
GvS: There is a great amount of synergy between the two. And actually, how much easier would it be to have “Standard Changes” in the change management process, enrich a CMDB with actual data that isn’t stale, have service models up to date and have focused problem management.
ANBU: A well defined devops strategy can help you implement ITIL more effectively. Configuration management and release management are two particular areas where the ITIL can provide the maximum benefits to the CD strategy.
10. Jez Humble and David Farley suggest not using feature branching, because this incourages back room channel development, and to only use the master branch to do CD, but other companies in this space says feature branching is ideal because git-flow encourages this, is there a prefered strategy in your branching strategy to do CD. Is there a need to better define what is meant by ‘continuous delivery’? I am concerned with people stating that CD means code gets in untested (which is from my understanding an anti definition) and fully tested code is a part of CD.
GvS: I believe Jez’ argument, and I agree, is why it is essential to have a deployment pipeline that is triggered off trunk to ensure all necessary validations, including functional testing. A deployment pipeline is a pattern that organizations adopting CD use. The key is that the validations should be performed against a build off mainline. I also advocate a number of good approaches that help in the validation effort, such as automating the generation of functional tests and having the right data sets available for relevant validations.
ANBU: No comments.
11. Does continue delivery means continuous Deployment to production? For Horses, frequency of deployment is not too frequent but they would still need to have Continue delivery to achieve benefits of Test Automation, Agile Methodology etc.
GvS: I would argue no. Continuous delivery does not equate continuous deployment to production. If I may be so bold, I would state continuous delivery is a practice to allow deployment to production at any time with a high degree of quality and a low amount of risk with zero downtime and zero touch. A business leader recently said to me that whereas, in the past, “deployment to production was an IT decision, it is now a business decision at a push of a button”. But, CD certainly played a part in this paradigm shift, as the entire delivery process, including testing, is visible and predictable.
ANBU: Continuous Production deployment is not the ultimate goal of CD. It is to let you manage multiple workstreams in parallel as atomic units, accelerate quality through high degree of automation and provide an ability to learn/continuously improve the processes. By means of this, you make your changes ready to be deployed faster than you normally do. You should aim to achieve the frictionless automation across the life-cycle, not just in QA activities.
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
Julie Craig, Research Director at Enterprise Management Associates (EMA)
At EMA, Julie’s focus areas are Application Management, public and hybrid Cloud, Integration Technologies, DevOps/Continuous Delivery, and Application Performance (APM). Julie has over 20 years of deep and broad experience in software engineering, IT infrastructure and integration engineering, and enterprise management. Her experience in commercial software companies included development of communications interfaces and management of programming teams. Georg von Sperling, DevOps and Technology Evangelist at CA Technologies
Helping organizations adopt Continuous Delivery without creating more technical debt, Georg is a practitioner, an evangelist and a general geek on software development methodologies, technology, patterns, systems and delivery practices. He advises, helps customers visualize, plan and implement transformational approaches to delivering digital assets from idea to production for medium to large enterprise organizations.
Anbu G. Muppidathi, Vice President at Cognizant Technology Solutions
Anbu has over 25 years of experience in the IT industry and is with Cognizant for the past 20 years. Anbu’s customer management responsibilities include advising the C-suite on breakthrough thinking, competitiveness, strategy, operations and transformation. His business management responsibilities include strategizing on QE&A business unit’s growth, managing the customer relationship, delivery and business operations for the customer engagements in Americas. Prior to QE&A, Anbu was with Cognizant’s Banking & Financial Services vertical for more than a decade managing a large portfolio of North American customers.
The financial services industry has changed more in the last 15 years than in the previous thousand. Customers expect constant access through secure mobile interactions with providers; interactions that no longer take place within the four walls of a bank. At the same time, financial services companies are dealing with ever-growing regulation.
Join Sander Ettema, Manager, Linux Infrastructure Services at Rabobank and Andrew Phillips, VP, Products for XebiaLabs as they examine how Rabobank has transformed its software delivery by implementing Agile development, Continuous Integration and Continuous Delivery. Learn tips on how to stay ahead of the curve in an age where the competitive landscape is shifting at light speed and rapidly moving beyond other financial services companies to include tech giants like Google and Apple.
Attend and learn how to:
Create a culture of innovation and adapt your IT organization for rapid change.
Deliver on customer expectations by modernizing your IT software delivery landscape with an open platform for Continuous Delivery.
Get started quickly and leverage your existing IT infrastructure for rapid results and understand the key metrics to watch along the way.
Lead an IT transformation in the highly regulated environment of financial services.
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
Andrew Phillips
VP, Products, XebiaLabs
Andrew Phillips heads up product management at XebiaLabs where he drives product direction, positioning and planning. He is an evangelist and thought leader in the DevOps, Cloud and Delivery Automation space.
Sander Ettema
Manager, Infrastructure Linux Services, Rabobank
Sander Ettema manages Linux/Unix Infrastructure Services for Rabobank, a global leader in food and agri financing and sustainability-oriented banking. In addition to being a member of the DevOps workgroup, Sander oversees Linux/Unix/Appliances Hosting, Continuous Delivery services for Java as well as log management services.
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.
Gus Reiber, Senior UI Developer, CloudBees, Inc.
Gary Gruver, President at Practical Large Scale Agile
Jim Bugwadia, Founder & CEO, Nirmata
Shane Johnson, Sr. Product Marketing Manager, Couchbase
Topher Marie, CTO of JumpCloud
Amrit Williams, Chief Technology Officer, Cloud Passage
Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her 
Udaypal Aarkoti is the Director of Solution Architecture at CloudBees. He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat.
Georg von Sperling, DevOps and Technology Evangelist at CA Technologies
Anbu G. Muppidathi, Vice President at Cognizant Technology Solutions
Sander Ettema