devopsy.kinsta.cloud

Tag: Jenkins World 2017

  • Total DevOps is Needed, Plugins are Not Enough

    Total DevOps is Needed, Plugins are Not Enough

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

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

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

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

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

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

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

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

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

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

    — Marc Hornbeek

  • XebiaLabs Shows Off ARA, More at Jenkins World

    XebiaLabs Shows Off ARA, More at Jenkins World

    In this third spotlight on companies attending Jenkns World, another worth checking out came to mind, so I am taking a look at what XebiaLabs intends to do while there. XebiaLabs is one of the leading application release automation (ARA) vendors, and has a long history of working with Jenkins, so it’s a little more mainstream than the other companies I’ve written about.

    But the thing is that Jenkins’ and XebiaLabs’ tools do work well together, offering an end-to-end build/deploy process that is repeatable and can be repurposed for different targets or different applications.

    While Jenkins handles CI/CD, XebiaLabs ties in the deployment pieces to complete the picture and make a streamlined system. When I experimented with XL Release and XL Deploy, I used them to call Jenkins as part of the release process. Interestingly, you can also call them from within Jenkins, which dovetails well with what another vendor I looked at—CloudCoreo—is doing. The ability to control the process from Jenkins is nice and has uses in the early development phases, but XebiaLabs raises the level of release management—something Jenkins is not doing (yet). The bit that ties CI/CD to automated deployment should be running the show, IMO. But I can imagine environments where kicking off all the build/release cycle from within a Jenkins job would be the preference.

    Anyway, on to what XebiaLabs is doing at Jenkins World!

    Key for XebiaLabs this year will be showcasing its DevOps platform, which is both XL products and talking about how the company is advancing integration between these products and Jenkins. Its recent Templates as Code (the link is to an earlier version, from January, but talks about its goals with Templates as Code, so it’s a good start if this is new to you) implementation that made it easier for developers to work with its products is being enhanced, and I’d love it if someone took a look at it and told me what they think. I can probably get someone at XebiaLabs on the phone to talk about it, but real users often have a better take on suitability in the wild.

    The important bit for many of you will be XebiaLabs’ Periodic Table of DevOps Tools, which I know several people would love to have as a poster in their office. For cool factor, it’s hard to beat. The company will have tubes with the periodic table available, so drop by to snag one. Last year it ran out of them relatively quickly, so be early. Bonus points to anyone who snags an extra and sends it to me for my office (ha ha).

    Aside from the Periodic Table of DevOps, XebiaLabs also will have copies of “The DevOps Handbook,” which I recommend. For those who haven’t read it, the format is different than “The Phoenix Project,” but it is the next logical step in that progression. Finally, the company will have its own book, “The IT Manager’s Guide to Continuous Delivery,” which I haven’t read, but having read XebiaLabs’ corporate blog for a while now, I predict will have some good ideas in it.

    I admit an interest in how recent changes to XebiaLabs’ DevOps platform improve the experience across the org (or don’t improve it). I haven’t used its tools since the new “pipeline as code” changes were introduced in January, so I honestly have no idea. If you go and stick around for a demo, let me know what you think.

    — Don Macvittie

  • CloudCoreo: Get Your Cloud Security on at Jenkins World

    CloudCoreo: Get Your Cloud Security on at Jenkins World

    I mentioned in a previous blog post that I’d take some more of the people pinging me about Jenkins World 2017 and post about them. One of the companies I’ve picked to highlight is CloudCoreo, makers of AWS security controls and auditing.

    Disclosure: My company, Ingrained Technology, has a business relationship with CloudCoreo outside of our relationship with devopsy.kinsta.cloud. That’s how I know about their attendance. But they’re a cool company for cloud security automation, so I chose to include them in my Jenkins World previews.

    CloudCoreo is based on the premise: What if you could automate and audit security settings in AWS without learning security for each of their services? I’ve used their tools, and I’ll be honest, my personal AWS account had a bunch of security violations. Since I use AWS off and on in spurts, this makes perfect sense, and I was able to clean house a bit based upon the tools’ feedback.

    CloudCoreo’s presence at Jenkins’ World will be to talk about itsr system, but will also concern its new Jenkins’ plugin. While there are tools that allow you to partially automate security generation in AWS, the cool part of the plugin is that it allows your automated system to audit the actual results of a deployment to check against standard security patterns. And those checks include things that are normally outside the build/deploy process, such as user rights and password change frequency.

    One of the directions that cloud is going is putting security configuration directly into templates. But not every template will be designed with the same level of configuration/security. By auditing the results as part of a deploy, weaknesses in templates obtained from external sources easily can be detected early in the development process. This is fully in line with the “shift left” approach currently being used in DevOps, and gives security an edge in automating one more thing. If it is just part of the deployment to kick off this Jenkins plug-in as one of the final steps of deployment, then security can shift from “pawing through tons of config code” to “reviewing results.”

    Right now, security is one of a few items (NetOps being the other) that is on the critical path for DevOps to be both responsive and controlled. Companies such as CloudCoreo are helping make certain that not only does it go out quickly, but it goes out secure.

    I haven’t tried its Jenkins plug-in yet, and don’t currently have any complex AWS projects going on, but the thought intrigues me. Someone should go stop by (the company will be giving a demo of stopping a release for violations at table T1) and see it in action, then report back what you learn. Having used CloudCoreo’s web interface, I expect the results of the Jenkins plugin will be both thorough and definitive, but verification of those suspicions would be nice.

    — Don Macvittie