Category: Features

  • DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps

    DOES UK: Nike Applies ‘Just Do It’ Attitude to DevOps

    Nike’s DevOps transformation has had a lasting impact on its culture and productivity, while allowing the company to connect with its customer in ways it never could before. Its journey down the path to DevOps was shared at the DevOps Enterprise Summit (DOES UK) 2018,  in London.

    For a company of its size and success in the current market to take a giant leap of faith and come out even more successful takes incredible courage, hard work and collaboration. But that’s Nike for you: Shoes, apparel or DevOps—it doesn’t make a difference to the company. From day 1, Nike has lived its mantra, “Just Do It!”

    Imagine this: You’re a high-level IT employee at a non-technology-focused company with a market value of just over $110 billion. All of a sudden, the newly appointed CEO makes the most significant announcement in recent history of the company, essentially saying, “We are entering a new era of growth and we expect to use technology as our main way of getting closer to the customer.” Pretty crazy, huh?

    This was reality for Randy Lyons, a longtime employee at Nike with an extremely strong taste for competition and the opportunity of a lifetime in his hands. Based in the EMEA region, Lyons teamed with global Nike CFO Michelle Power with one goal in mind: to bring customers closer to the products, available at any of their 7,000 branded stores globally, through a digital platform. The aim was to tap into consumers’ need to check our phones before making a purchase. The scale was momentous; arguably, larger than any other company achieving a successful DevOps or Agile transformation before. To pull this off on the scale CEO Mark Parker had intended, a complete culture shift was necessary.

    Luckily, the unlikely team shared the motto, “Culture eats strategy for breakfast,” and they were eager for the challenge. To start, they needed to change the self-identity of the IT branch. For too long had the underutilized IT staff heard the narrative that “technology helps the business succeed,” rather than existing as a part of the business. Lyons and Power placed a heavy emphasis on the new role of cross-functional IT teams as an integral part of the company rather than a useful helper. They adopted the hashtag “#OneTeam,” which promoted interaction and alignment of the tech team with all other teams, and showed everyone working for them that they were fully invested and energized in positively changing the culture and structural hierarchy of Nike. Additionally, they sought to point out the impact each person’s work was playing through the lens of the overall strategy. The “How is what I’m working on going to effect the direction of this company?” question versus “What else do you need me to do?” was a significant change—it boosted the overall motivation of the teams to work together and even raised individual production significantly.

    However, the transformation was only beginning. Early on Power and Lyons discovered a fundamental flaw in the company they sought to transform: Their employees didn’t feel rewarded for their work. While it might be easy for some companies to blow off this issue in favor of dealing with “bigger” issues, they wanted to promote a company culture that would foster growth and speed, which would not—or could not—happen unless their teams felt beyond satisfied with their workplace environment. So, instead of the annual award ceremony Nike regularly used to reward and congratulate its employees, Lyons and Power decided to implement a simple change they felt would satisfy everyone: They added 15 minutes to the end of their weekly Friday staff meeting to give shout-outs everyone who had performed above expectations on a project. It was awkward at first, Lyons admitted. He also described it as “quite American” (ha ha)! However, this simple idea created a complete culture shift. Suddenly, the tech team was being praised by the supply team, while the supply team was being praised by the sales team, and the sales team was being praised by the tech team. This weekly validation of a job well done turned into more jobs well done!

    Ultimately, the agile teams were motivated enough and aligned in such an efficient way that they were able to produce five separate software systems fully integrated into a single one-member profile:

    1. com (full selection of products sold in store)
    2. Nike app (for a more personalized experience)
    3. Sneakers (collection of shoes sold in store)
    4. NRC (for running products)
    5. NTC (for training products)

    These software products were incredibly effective in creating an emotional attachment with the brand and the products. Finally, the goal of getting the customer closer to the product through a digital interface had been achieved. The process to get there wasn’t easy. There were many problems to overcome and many things that changed drastically to allow for a newer and more efficient way of doing things. However, Lyons noted this transformation was the most influential on a personal level for him: Before undertaking this project, he didn’t feel as though he could effectively serve as both a team leader and participant. He could easily take orders and sometimes give them out, but it wasn’t until he partnered with Power that he learned to become a not just a team player, but the best player on his team.

    The DevOps journey was a transformational process for both the company and the people involved. Today, “Just Do It” means exponentially more to Nike than just a slogan—it’s a way of adding value and efficiency to business.

    This was just one of many of great presentations at this years DevOps Enterprise Summit UK this past week. We will be highlighting others in the days ahead.

    — Landon Shimel

  • Splunk Pushes Into the Realm of DevOps

    Splunk Pushes Into the Realm of DevOps

    On the heels of its recent acquisition of VictorOps, provider of incident management software, for $120 million, Splunk is gearing up to expand its foothold in DevOps significantly.

    Rick Fitz, senior vice president of IT Markets for Splunk, said the provider of widely used operational analytics software in the enterprise sees a significant opportunity to expand its presence across a range of DevOps processes.

    Incident management is a natural extension of operational analytics, said Fitz, noting Splunk chose to acquire VictorOps because the investments the company has made in applying machine learning algorithms to monitoring IT events. That approach significantly reduces the number of irrelevant alerts being generated and provides actionable intelligence into potential events that could adversely impact IT operations.

    Most IT operations teams suffer from alert fatigue, Fitz noted, and most alerts are ignored because of a lack of context. The combination of Splunk and VictorOps will result in alerts that more precisely identify the root cause of any IT issue, he said, and a better overall “systems of engagement” for IT operations teams in keeping with DevOps principles.

    Splunk has been steadily expanding its focus on DevOps. Earlier this year the company announced Splunk Insights for Infrastructure, which IT organizations can host on an Amazon Web Services (AWS) public cloud to monitor IT infrastructure deployed anywhere. The latest versions of Splunk Cloud and Splunk Enterprise also make use of machine learning algorithms on top of a revamped metrics engine that enables IT administrators to monitor everything from CPU speeds and available hard disk space to temperature readings in internet of things (IoT) devices and sensors. Splunk recently also added connectors for Docker and Kubernetes, as well as the Apache Kafka messaging platform for streaming data in real time.

    IT operations and cybersecurity teams already rely on Splunk operational analytics software extensively to identify anomalies. By investing in machine learning algorithms and acquiring incident management software, Splunk is moving to turn all the data it analyzes into actionable intelligence, which then could be shared in real time with developers to ensure application availability and optimize application performance.

    While adoption of DevOps processes in traditional enterprise IT organizations remains spotty, IT vendors that focus on IT operations such as Splunk have clearly seen the writing on the wall. Fitz noted that investments made in machine learning algorithms, for example, will enable IT operations teams to more respond to changing application requirements with greater agility at a time when the IT environment has become exceedingly complex. That agility is critical for any organization engaged in digital business transformation, Fitz said, because invariably those efforts lead to more applications being deployed.

    It’s not clear the degree to which incumbent providers of IT operations software will be able to remain relevant in the age of DevOps. But most of them certainly have the financial resources to at the very least acquire a portfolio of DevOps tools that will enable them to exert a lot more influence than many of them have to date.

    — Mike Vizard

  • What Comes after DevOps? Two Possibilities

    What Comes after DevOps? Two Possibilities

    People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

    The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

    At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

    Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

    That begs the question: What comes after DevOps? I think there are two distinct possibilities.

    A Reaction Against DevOps

    One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

    Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

    But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

    In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

    DevOps-ifying the Whole Organization

    The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.

    This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

    Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

    To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

    — Chris Tozzi

  • Tricentis, QASymphony Merge: The Age of Continuous Testing Is Upon Us

    Tricentis, QASymphony Merge: The Age of Continuous Testing Is Upon Us

    Big news in the world of continuous testing today as continuous testing market leader Tricentis announced it is merging with QASymphony. Tricentis, a leader of continuous testing, is adding QASymphony’s leading testing automation platform to the mix. The full text of the press release is below.

    With the worldwide testing market pegged at more than $34 billion, this is a big move in a very big market. Tricentis raised $165 million last year from Insight Venture Partners and has put this money to good use: The QASymphony merger is Tricentis’ latest move. Previously, it acquired Q-Up, in June, and last year acquired Flood IO.

    Tricentis’ merger with QASymphony is happening at a time when continuous testing is becoming one of the hottest areas in DevOps. The demand for automated, continuous testing is driving a revolution in the QA market as companies recognize that quality is as important as speed when it comes to deploying new apps. It is a key cog in the modern software factory.

    I had a chance to sit down and speak with Tricentis CEO,  Sandeep Johri, about today’s announcement, the testing market and what the future may hold. Sandeep, who has previous experience at HP and other large providers, has a great vision of the market and where it is heading as well as the details that escape many “professional manager” CEOs. His hand is firmly on the wheel as he drives Tricentis forward in this space.

    Have a listen to our conversation below, and stay tuned—we will update and continue this breaking story as more details emerge.

     

    Tricentis and QASymphony Merge to Drive Innovation in Continuous Testing for Enterprise DevOps

    Next Gen platform disrupts the $34B testing services spend and transforms software testing for DevOps

    Mountain View, CA— June 20, 2018 — Tricentis and QASymphony announced their agreement to merge under the name of Tricentis. Tricentis’ market-leading Continuous Testing platform has earned the company unanimous “leader” recognition among the top industry analysts. QASymphony is recognized as the industry’s leading test management solution. The combined solution represents the most modern platform for transforming software testing to keep pace with digital transformation.

    “Tricentis and QASymphony are both recognized for their innovative testing solutions,” explained Sandeep Johri, CEO of Tricentis. “Tricentis is known for helping enterprises transform testing from a burdensome manual process that delays software delivery into an automated, continuous process that drives ‘quality at speed.’ The addition of QASymphony’s test management solution strengthens our leadership position and builds on our momentum replacing legacy testing tools.”

    “Today’s CIOs are responsible for ramping up innovation through accelerated software delivery,” explained Barry Libenson, Global Chief Information Officer at Experian. “Amid this demand for rapid innovation, CIOs are recognizing that software testing often delays their digital transformation goals. In fact, testing is now commonly cited as the #1 bottleneck to delivery speed. When testing lags behind development, the organization is forced to delay their innovation and that’s no longer an option. It’s inevitable that software testing must be transformed to keep pace with Agile development and DevOps.”

    “Global 2000 organizations remain locked into legacy testing platforms that were designed decades ago to enable manual testing processes,” explained Dave Keil, CEO of QASymphony. “Scaled agile and enterprise DevOps initiatives have changed the game. Yet, legacy testing technologies such as those by HPE (now Micro Focus) and CA are throttling speed and innovation. QASymphony has experienced triple-digit growth over the past year—allowing us to aggressively invest in our technology, infrastructure and people to meet the emerging needs of our customers.”

    QASymphony’s 100+ employees will be joining Tricentis’ 450+ employees. Sandeep Johri will lead the organization as CEO and Dave Keil will assume the role of COO. The combined company will have a global presence with offices in the US, EMEA and Asia. The transaction is expected to close within 90 days. EMBARGO UNTIL WEDNESDAY, JUNE 20, 2018 @ 8:00 AM ET USA

    The integration will reflect the commitment to innovation and customer success that both companies share—to learn more, register for the upcoming webinar. Additionally, the company will be showcasing the roadmap and solution at Accelerate 2018 in Vienna.

    DevOps Impact

    The market for software testing (recently estimated at $34 billion)1 has reached an inflection point. DevOps adoption is rising rapidly, and both Gartner and Forrester report that transforming testing is a primary factor for DevOps success.2 Yet, software testing remains a predominantly manual activity that delays releases and consumes 30-40 percent of an organization’s application budget3,4 Tricentis Continuous Testing solutions accelerate delivery and free up significant budget that can be reallocated to underfunded innovation initiatives.

    Gartner’s Joachim Herschmann and Thomas Murphy report: “As DevOps principles gain significant traction in enterprises, testing and QA is no longer a stage in delivery but an integral DevOps activity that exists in various forms through all areas. Automation has become an indispensable element in these efforts, and there has been renewed focus on software test automation tools as part of a larger toolchain that enables DevOps.”5

    About Tricentis

    With the industry’s No. 1 Continuous Testing platform, Tricentis is recognized for reinventing software testing for DevOps. Through risk-based testing, scriptless end-to-end test automation, and the industry’s most extensive technology support, Tricentis breaks through the barriers experienced with conventional software testing methods. Our innovative technologies simplify testing for even the most complex enterprise applications—transforming testing from a roadblock to a catalyst for innovation. The result is accelerated software delivery speed, improved cost efficiency, and reduced business risk.

    Tricentis is the only vendor to achieve “leader” status in all three top analyst reports (i.e., the “Triple Crown.”) This honor is based on our technical leadership, innovation, and a Global 2000 customer base of 800+ companies, including global enterprises such as Allianz, ANZ Bank, Experian, First Data, HSBC, Lexmark, Merck, Sentry Insurance, Starbucks, Telstra, UBS, Vantiv (now WorldPay), Vodafone, and Whole Foods. These customers rely on Tricentis to achieve and sustain test automation rates of over 90 percent—increasing risk coverage while accelerating testing to keep pace with Agile and DevOps. EMBARGO UNTIL WEDNESDAY, JUNE 20, 2018 @ 8:00 AM ET USA

    Tricentis has a global presence in Austria, Australia, Belgium, Denmark, Germany, India, Netherlands, Singapore, Switzerland, Poland, United States and the UK. To learn more, visit https://www.tricentis.com or follow us on LinkedIn, Twitter, and Facebook.

    About QASymphony

    QASymphony accelerates digital transformation with software testing solutions that help enterprises prioritize quality, develop reliable software and increase speed to market. The qTest platform streamlines software testing in agile and DevOps environments and centralizes testing efforts across the enterprise. By taking a strategic approach to quality, QASymphony enables enterprises to develop higher-quality software, faster, to better support new business models and customer experiences.

    The qTest platform streamlines development workflows by seamlessly integrating testing with leading automation, development and delivery tools including Atlassian’s Jira, CA Agile Central, Github, Selenium, Cucumber, Jenkins and many more. QASymphony is trusted by leading enterprises including Forcepoint, PFSweb, Cisco, Samsung, Verizon and Office Depot.

    1 Nelson Hall, https://research.nelson-hall.com/sourcing-expertise/it-services/software-testing/

    2 Gartner, Build Continuous Quality Into Your DevOps Toolchains: https://www.gartner.com/doc/3868367/build-continuous-quality-devops-toolchains

    3 Capgemini, HPE, Sogeti, World Quality Report: https://www.capgemini.com/service/world-quality-report-2017-18/

    4 Capgemini, HPE, Sogeti, World Quality Report: https://www.capgemini.com/service/world-quality-report-2017-18/

    5 Gartner, Magic Quadrant for Software Test Automation: https://www.gartner.com/doc/3830082/magic-quadrant-software-test-automation

    Media Contact

    Victoria Brown, Revere

    +1 (650) 850-2009

    Victoria.brown@revereagency.co

    QASymphony Contact Information Kira Mondrus

    QASymphony +1 (844) 798-4386 Kiramondrus@qasymphony.com

    Tricentis Contact Information

    Noel Wurst, Tricentis +1 (904) 673-4427 n.wurst@tricentis.com

    — Alan Shimel

  • DevOps: The Things We Must Stop

    DevOps: The Things We Must Stop

    Anytime there is a popular movement in technology (and I would argue any other field), people get carried away. We’ve seen it over and over, and DevOps attracts this kind of attention. In fact, DevOps caters to those who get carried away by mainstream folks screaming, “THIS CHANGES EVERYTHING!” That type of hyperbole pushes those who get carried away even further. And marketing always takes things to whatever place they have to in order to, well, sell their ideas to the market.

    Rack ’em Stack ’em Robots

    My all-time favorite purposeful over-the-top is the tendency to pretend that prior to the cloud, every project was started with “rack ’em, stack ’em.” This is demonstrably false, as by the time the cloud was taking off, VMware’s market penetration was significant. And yet, the number of blogs/amount of marketing material that starts out with the premise that every application required waiting for physical server delivery and configuration is insanely high.

    No. Enterprises, in particular, had to wait for VM allocation and configuration.

    Another that isn’t really mainstream—and I’ve mentioned in other locations—is the AWS TCO calculator. The simple calculator is not a bad tool, and I’ve used it numerous times in the past, but the TCO calculator makes some assumptions about deployment costs that are a little wild, such as that TCO includes the cost of VMware and its supporting hardware for an individual app. Of course, that’s not how enterprises do it. There is a VMware infrastructure and it is shared across apps. While it would increase the complexity a tiny bit, a simple checkbox that asks, “Do you already have a VMware cluster?” would go a long way—or better, one that asks how many apps you are running on VMware and divides the overhead by that number before including it in TCO. But of course, if you are getting your TCO comparisons from a competitor, expect the TCO will be stilted, no matter who is generating it.

    Oversimplification

    Whether it is infrastructure orchestration or app deployment, there is a lot of content out there that talks about how much easier infrastructure as code will be, and how much less documentation we will need. This, sadly, is a bogus premise. Whether you’re using the 50,000 service offerings of AWS or the power of HashiCorp’s Terraform—or any of half a dozen other competitors—it is complex. We’re not doing anyone any favors by glossing over the complexity that inevitably occurs in enterprise-class deployments, and we’re doing a massive disservice every time someone claims that documentation needs will be less because it’s “self-documenting code.” Self-documenting code sucks without a ton of comments in App Dev, and it’s worse in deployment. Employees new to the process need, and should be provided, solid documentation on how the system works and where different pieces fit.

    We’re deploying complex apps on complex infrastructures with evermore complex compliance and security requirements. It is not simple.

    All or Nothing

    There is a belief among too many aficionados that their way is the “One True Way.” The fact of the matter is that all enterprise application portfolios are complex and there is a metric ton of extant code that must be managed. A startup with one web-based app (no matter how large it may be) or a games developer focused on Android as its only platform might well have agile and DevOps as their only development/deployment methodology. No one else does. The enterprise running a hundred or a thousand different apps on several platforms is not going to flick a switch and say, “We’re all X now,” no matter what X is. Anyone who has tried to standardize the database in an enterprise knows that just doesn’t happen (I did, as an architect in a financial services org. It was ugly).

    Some projects are simply great fits for agile and DevOps—those with a high rate of change, where a little bit of instability in return for rapid feature rollout—while others simply are not—ones that maintain data that must be rock-solid, ones with a low level of change, etc. Any given enterprise is a mix of these things. Back in the days of the language wars, I used to say, “Right tool for the job,” and today, in the days of the architecture/automation wars, I say the same thing. If the project is rapidly evolving and you want lots of small changes in a constant stream, agile and DevOps are the right tools. If the project moves slowly and has an emphasis on stability or data quality, it’s not a great candidate for these tools at this time.

    I’ve talked about some of the bad vendors in this post, so I’ll call out IBM for being a good vendor on this point. Looking at the company’s model for moving the mainframe is a good example of how you could look at all of your IT, because IBM doesn’t say, “This changes everything!” It says, “Here’s how to tell what offers the most bang for the buck in moving to agile and DevOps.”

    Just Keep Rocking It

    Working in IT? You’ve been keeping your org running. Don’t start second-guessing your gut now just because the new shiny is being waved in front of you. Learn, change, do. But don’t rush into something with misinformation. Obey your gut and keep rocking your org’s world.

    — Don Macvittie

  • Picking a Git for the Enterprise

    Picking a Git for the Enterprise

    Some of my Agile and DevOps transformation work, not surprisingly, involves helping clients with tooling adoption—to set up, scale and operate across the organization. This blog piece is about a recent experience of setting up Git across a client organization.

    Git, as most of you are aware, is a fundamental building block for many of the modern engineering practices associated with Agile and DevOps. Software configuration management tools such as Git, in simple words, allow you to track and manage your software code and configuration changes in the most-effective, efficient and distributed way. Git, as the choice of source control, has remained steadfast over the years, while other tools across various categories of DevOps tools have seen their fortunes go up and down with the ever-changing technology landscape of DevOps tools. In fact, one new buzzword is GitOps—some even calling it the next stage of evolution for DevOps.

    Origins of Git

    More than a decade ago , the Linux community faced a challenge  because none of the existing revision control tools met their need for a distributed version control tool. And from that need Git was born. In the words of the creator of Git, Linus Torvalds, “The main issues with SCMs is the politics around who can make changes.” Ever since its creation, Git has radically changed the notion of software configuration management (SCM), by enabling engineers to work remotely and autonomously. (If you are new to Git and interested in exploring more about Git and its features, Atlassian has a tutorial and GitHub has a list of resources.)

    Git and More

    While Git as the core product is fundamentally the same whichever flavor your prefer—GitHub, GitLab or Bitbucket—the wrapper around it determines the important non-functional characteristics such as operatability, security, usability and maintainability. Our quest for an enterprise-scale Git focused on the wrapper and not the core product itself, as much has been written, debated and documented on the core product of Git itself already. The value and relevance to enterprises is in the wrapper that these productsplatforms provide.

    We looked at the core product and related offerings; as you can imagine, the three tooling vendors have different positioning and taking different directions with the future road map for their respective tools. Bitbucket’s strength lies in the fact that Atlassian is bundling the product with the omnipresent Jira Software and Confluence. GitLab’s road map seems to be taking the product beyond Git and into the idea of a single product for your entire pipeline automation, from concept to cash. GitHub, which is being acquired by Microsoft, is increasingly relying on the strength of integrations with other tools and the workflow capability the company is bundling with it.

    (I avoid an overemphasis on the commercial aspect in this blog; however, I’m not ignoring it completely. Part of the reason is due to the fact that enterprise pricing is not entirely transparent and may vary wildly depending on organization’s negotiating capability, the scale of usage, future potential and marketable track records as perceived by the tooling vendors. This blog is also not meant to be a feature by feature comparison, as this is something you can Google and find out yourself very easily.)

     

    The Verdict

    Github Enterprise pros and cons
    Image1; Github Enterprise – Pros and Cons
    Gitlab Ultimate and features
    Image 2:  Gitlab Ultimate – Pros and Cons

    My Recommendation: It Depends

    1. I liked the vision of GitLab as a single-stop tooling platform for continuous integration/continuous delivery (CI/CD), which goes beyond source control. I think the tool is simple and intuitive to use and great for small to midsized setups or even large enterprises that are focused on having smaller and autonomous teams.
    2. GitHub seems to be well-suited for large and complex enterprises with significant outsourced and offshore-based technology teams.

    I would love to hear your views on what has been your thinking with regards to choosing a Git-based product for your enterprise or teams. Meanwhile, here are some links you might find useful in your decision-making:

    1. Why and how GitLab abandoned Microsoft Azure for Google Cloud – https://venturebeat.com/2018/04/06/why-and-how-gitlab-abandoned-microsoft-azure-for-google-cloud/
    2. Tooling integrations of GitLab – https://docs.gitlab.com/ee/integration/README.html#doc-nav%20for%20list%20of%20integrations
    3. GitHub add-ons are listed at Addons are listed at https://github.com/marketplace
    4. Security and scalability info of GitHub is at https://github.com/jonico/github_security_and_scalability_overview
    5. Products that integrate with GitHub platform – https://github.com/works-with
    6. Pricing of GitLab – https://about.gitlab.com/pricing/

    — Aditya Vadaganadam

  • Why Open Banking Should Consider DevOps

    Why Open Banking Should Consider DevOps

    There is a craze sweeping Europe, and rippling across the world—and no, I’m not talking about the next British Invasion. Open banking is a trend that’s significantly altering how banks work with fintechs and maintain agility in the global marketplace.

    A main enforcer is PSD2, a piece of EU legislation that sanctions access to personal banking data. It’s resulted in an explosion of EU banks providing public application programming interfaces (APIs) for fintechs to develop with. The implications aren’t limited to Europe; many banks all over the world are looking to PSD2 as a baseline, forcing some tough evaluation of how financial architecture should adapt.

    Banks are also under consumer threat to evolve or get out — a 2016 Accenture study found that 78 percent of respondents would bank with a tech firm such as Amazon or Google.

    As banks transition into savvy software providers due to market pressure, one thing is certain: they must adopt agile software development strategies that streamline the deployment and maintenance of these services. In other words, banks must adopt a DevOps philosophy to maintain a market advantage.

    Open Banking Evolves Bank Architecture

    The bank has become programmable. Many banks are now required to allow third-party authentication and access to payment, account information, fee details and other data. This involves support for various integration methods; SDKs, APIs and OAuth for authentication, as well as documentation, sandboxes and other developer tools. Whether they like it or not, banks are now SaaS providers.

    It should be noted too that open banking is not limited to the European Union. The UK’s open banking standard is the Competition and Markets Authority (CMA), and Australia, Japan and other countries are making similar inroads with regulating banking data. The excitement has also encouraged North and South American players to open up.

    The new bank APIs help bypass traditional methods, saving a ton of time. In an article in American Banker, BBVA noted that online e-commerce system Dwolla was able to slash the typical three-day to six-day deposit time frame using their payment APIs. “We’re allowing that all to occur in real-time,” said Chad Ballard, director of mobility and new digital business technologies at BBVA Compass.

    Letting FinTechs focus on web UI development helps banks focus on their core competencies: banking and authentication. Establishing connections via API-driven microservices is also a safer alternative to screen-scraping.

    Why DevOps for Banking?

    Banking Exchange defines agile banking as “the future of retaining relevancy for banking as a whole.” For open banking to be successful, the platform must be tested, monitored and secured for fintech consumers. Sounds a lot like the hallmarks of quality DevOps practice.

    Popular services Google Maps, Uber, Stripe, Twilio and others have adopted an API-as-a-product mentality. These programs adhere to best practices, iterative feedback and agile development methodologies to excel. Similarly, for banks to remain competitive, they must treat their platform architecture and public gateways with the same tenacity.

    For banks, uniting iterative development with stability testing—essentially the Dev + Ops mantra—for their APIs, microservices and frameworks will go a long way to help reach open banking goals and maintain future regulations on API performance standards.

    A DevOps mindset is crucial to consider early on in the open banking journey, as it can impact how banks address:

    • Iterative development and testing: By tying in iterative development with stability testing, organizations can surpass the time limitation often incurred between shipping versions between development teams and testing teams.
    • Continuous monitoring: Many tools are available to monitor the CI/CD pipeline, helping banks respond to issues and improve uptime.
    • Versioning strategies: DevOps in banking will see the larger picture, working in the REST mantra to build on the scale of decades to avoid breaking change.
    • Transition to microservices: As enterprises dispose old monolithic architectures, bitesize services are arguably more appropriate for modern banking; however, they come with unique caveats that DevOps can address.
    • Collaboration between silos: By pivoting to more point-to-point, collaborative processes, banks can reduce friction to meet the responsive expectations set by FinTech, who are becoming new public faces for banking.

    An end result of DevOps is to increase agility in an organization. Especially for large banks, this signifies drying up the traditional “waterfall” development life cycle known to stigmatize the corporate approval process.

    Case Studies: How Banks Are Utilizing A DevOps Cycle

    Many banks have been vocal about what they are doing to ignite positive technological innovation alongside third parties. For example, Capitol One’s DevExchange recently announced a new initiative called experimental APIs. “They are designed with the goal of getting early feedback from the community around API desirability and design before the product release,” the company noted in a blog post.

    In this experimental setup, operational cues inform development. Getting the two sides to talk and respond to community feedback is paramount for DevOps to succeed.

    For banks to adopt an agile makeup, Manfred Bortenschlager, Red Hat’s director of Business Development for API-based Integration Solutions and API Management, recommends what he calls an “agile integration.” This involves a distributed integration for greater flexibility, containerization for the ability to scale better and managed portals for reusability.

    Another interesting effort is that of CIBC, a Canadian bank that is responding to the open banking movement with a responsive microservices framework the company has developed using open source components.

    What’s evident is that many banks already acknowledge DevOps principles as key for innovation in their sector. Through the the use of iterative testing, innovative tooling and automated workflows, banks can achieve greater operational efficiency.

    Open Banking Must Follow Software Development Practices

    A result of the open banking movement is that banks must keep technological pace with fintech. Especially with regulatory pressure, banks must consider how best to approach new technological initiatives.

    DevOps is a way to mitigate concerns. As a philosophy for uniting technical procedures with responsive operations, it’s a prime strategy for banks to consider when readdressing their technology.

    In defining what “agile” embodies for banks, Steve Williams of Cornerstone Advisors said: “The idea is you need to start taking the management and operations of a financial organization and start adapting some of the things that have made technology companies viable.”

    American Banker echoes this, believing that “banks should be more like software companies.”

    Now prodded by open banking, it’s high noon for luddite banks to embrace contemporary software development practices; that means incorporating DevOps into the open banking agenda.

    — Bill Doerrfeld

  • DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    Post-DOES WorkshopGene Kim’s DevOps Enterprise Summit UK is just a few weeks away, June 25-26. While DOES UK this year is shaping up to be a must-see event, there are also some great events taking place around DOES. One is sponsored by Electric Cloud (also a founding sponsor of DOES). It is a post-DOES workshop, featuring classes taught by Gary Gruver, John Willis and Helen Beal.

    The workshop session lineup includes “DevSecOps,” by John Willis, “Leading the DeOps Transformation,” by Gary Gruver and “DevOps Essentials,” with Helen Beal. Helen’s DevOps essentials and Gary’s executive leader workshops are both half-days, so you can attend both. Each of these are great learning events as well as a great way to network with your peers. If you are in London on June 27, be sure to check them out.

    As usual, immediately below is the streaming audio of our conversation, followed by a transcript so you can follow along.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to a special edition of DevOps Chat. We have three folks on our panel for DevOps Chat today, and each one of them, actually, are really kind of special people to me within the DevOps community. And let me introduce them to you right off. First and foremost, ladies first.

    I want to introduce Helen Beal. Helen of course is DevOps fantastic at Ranger Four. But also, Helen was one of the first people I met in the DevOps community over in London and has been a friend ever since. Also has a position with the DevOps institute – an advisory role at DevOps institute as well. So Helen, welcome to DevOps cChat.

    Helen Beal: Thank you very much, it’s a pleasure to be here as always talking to you.

    Shimel: Thank you. My second guest really needs to introduction in the DevOps community. He has three – count them, one, two, three books around DevOps as well as many years of leading DevOps teams at HP and Macy’s and now consulting for many, many different organizations and helping them with their digital transformations and DevOps journeys, none other than Gary Gruver. Gary, welcome.

    Gary Gruver: Hi, thanks great to be here, nice to be speaking with you again.

    Shimel: Nice to have you here. And then certainly, last but not least – one of my good friends in the DevOps world, he runs marketing at Electric Cloud, which is also of course the founding partner of the DevOps enterprise summit (DOES) with Gene Kim and ITREV– Sam Fell. Sam, welcome.

    Sam Fell: Thank you, Alan. Happy to be here.

    Shimel: Okay, first thing I want to talk about today is we’re getting close to DOES London, which I believe is what? June 25 and 25 over at the O2 in London.

    And I know you’ll all be attending there and of course we can – Electric Cloud is again one of the founding sponsors and we can get all that information over on the IT revolution site. But part and parcel with Does London this year, I wanted to mention two special events taking place on the heels of Does London.

    One is a special post-Does workshop which, Sam, you and the Electric Cloud folks have driven. Why don’t you give us a little background here on what you guys are doing and why?

    Fell: Yeah, great – thanks, Alan, I appreciate that. So Gary – you mentioned, he has had all this experience helping these large  companies with their digital transformations. When we started our user conference back in 2013, Gene Kim came and spoke, Jez Humble came and spoke.

    And we were talking together, we said these are exactly the kind of people – these old horses that are trying to do these transformations that we want to try and attract to a large conference, which is sort of what the genesis of the DevOps enterprise summit. The folks that show up at that show, a lot of them are in a tough spot.

    They know they need to transform. Their business wants them to transform, they don’t know how to go about doing it. And so having a community of people that are available to talk to and learn from, admit mistakes to in a safe way, to know that you’re gonna get advice and counsel, it’s a fantastic show that the team has put together. And you can see by the success of it that the community really embraces it.

    So our thought last year with Gary was why don’t we take somebody who has helped companies with these transformations and go to DevOps enterprise summit and listen to those stories and see what people are going through and then directly after that you get in a room with an expert coach who can say, now, let’s apply that to you. Let’s apply that to your situation. All those stories that you’ve heard, how does that work for you?

    And last year we had just a fantastic time and so we decided to do the same thing this year at Does London. We’ll be doing the same thing at Does Los Vegas in October as well. And it’s just an opportunity for people to really put in practice and make real a lot of the things that they heard at the fantastic DevOps Enterprise Summit.

    Shimel: Fantastic, Sam. And it is, it’s a great workshop. Gary and Helen – before I jump over to you, Sam – I forget I apologize. For people to register for the workshop, what’s the cause? What’s involved? Where do they go?

    Fell: So it’s a heavily subsidized workshop. Helen, the DevOps institute, Gary, John Willis – these guys are giving their time in order to provide this for the community. Electric Cloud is helping to pay for the room and all this other stuff. So the cost is pretty minimal. I think it’s £195.00 for our early bird.

    We don’t have that many tickets eft but there are some tickets. There’s a group rate as well. So you know, non-expensive and it’s an opportunity for you to really rub elbows with people who are always wanting to learn how to do these types of things. And as you mentioned, John, we do have these couple different workshops.

    John Willis is doing Dev-Sec-Ops hands on technical workshop that same day. So we’ve got two tracks that we’ve got set up basically. I don’t want to spill the beans on what Helen and Gary are going to be talking about, but the John Willis workshop  we’re really excited about that. He’s gonna be showing people with a live pipeline how to incrementally improve it. how to bake security into your deployment pipelines.

    And one of the types of things that you can do to enable your teams and your developers to ship secure codes. Fantastic stuff.

    Shimel: Yeah, no, that’s gonna be a great hands on workshop for anyone interested in DevSecOps. We’ll have more info about DevSecOps in a little bit. But first, let’s turn to Gary. Gary – what is your workshop going to be about here?

    Gruver: I think I’m gonna follow your lead. Let’s go with Helen’s first with lady’s first and get to that and I think that’s the order that we’re going in with the day. Why don’t you lead off with Helen and then I’ll follow up.

    Shimel: Chivalry is not dead. Helen – go ahead.

    Beal: Thanks, Gary. So I’m going to be doing the half day DevOps institute course – the essentials of DevOps which essentially kind of what it says on the tin, the fundamentals or the foundation and relevance of DevOps and things like the three ways and coms and how it fits with Agile and IT send and Lean, PK studies, linking it to this integration.

    And continuous delivery. How they lead from one another. So that’s it. It’s a course really for people that are quite new to DevOps and they should expect to leave the course, really with an understanding of where DevOps has come from, why it’s important and what sort of business benefits people can anticipate from using DevOps practice and principles.

    Understanding some of the vocabulary that those of us that kind of live and breathe DevOps are quite familiar with. So things like the theory of constraints and CD and things like that and hopefully with some kind of action plan of what they can take back to their desk the next day and start making some DevOps differences in their own organization.

    Shimel: And it is the DevOps essentials course it’s really sort of a big time version of the full DevOps foundation, which Helen – you were instrumental in refreshing for this latest– I think it’s released three of DevOps foundation?

    Beal: Yeah, it’s very nearly ready. So it’s been updated with lots of additional case studies, we’ve updated things like the surveys too, the latest versions of the state of DevOps surveys. I know there’s another one coming out. I don’t think we’re expecting it for another few months, and actually part of what we’ve been doing this update is following our own principles. So we’re actually aiming for a much more incremental release cycle as we move forwards rather than in frequent big updates.

    I’m sure we’ll all be on board with that. And then, newer things have been coming through like liability engineering and more stuff around services and containers and those sort of things. Focused on safety culture, learning organizations and some of the things that John and Gene can cover in their beyond the finished product audiobook, also featured in there.

    As is some of the material from Nicole’s and Jane’s book – accelerate. And some references to that. And then we’ve removed some of the stuff that kind of isn’t really around anymore in the DevOps World.

    So things like NoOps – think it’s really gone away now. Rocket DevOps has been very overtaken by DevSecOps. So it’s a good solid refresh and hopefully the foundation will be able to keep refreshing it more frequently as this is such a fast changing world that we’re in – this DevOps world.

    Shimel: It certainly is. Okay, that’s fantastic Helen. And I encourage listeners that may be in the London area that week, if you’re near to DevOps or you really haven’t taken any formal DevOps sort of education or classes, you know, listening – goes to Does is a great way to learn from real life examples. But really this is a great class to give you a nice foundation in DevOps. Gary, how about you?

    Gruver: I’ll be doing my executive workshop that I do with most organizations when I go in and work with the executives to really help people put together their plans and figure out how do they approach it. The people that are gonna be at. Does are gonna be hearing a lot of different ideas, and a lot of perspectives on what they should be doing and I’ll hopefully be trying to help them put that in context.

    My big thing I champion is there are different approaches you need to use when you’ve got large tightly coupled systems than you do when you have small teams that can independently develop and qualify and deploy code. We’ll be going through a lot of those differences. We’ll be going through the role of the executive in terms of leading the transformation.

    A lot of this can be empowered if you have loosely coupled small teams but if you’ve got large groups of people who have to work together to coordinate the deployment pipeline in terms of being able to develop, qualify and release as a system, then you need to have the executives playing a pretty active role in coordinating the work across those teams and prioritizing the improvement. So we’ll be going through that.

    How do executives get the team all on the same page? And then how do you get them to a common definition of what they’re gonna go do and agree to that? So my analogy is a pipeline ____ described an elephant feels like most discussions I start with organizations that are starting to go down their DevOps transformation.

    And what I work to is a process and approach to give them a common view of the elephant and get people all rowing in the same direction. And helping people understand that the types of things they can and should do are different for large, tightly coupled systems versus loosely coupled systems. And then we’ll go through and we’ll help them understand where they should really be starting their transformation.

    Which is different for a lot of different organizations. And I feel that starting point is really important, because this is a lot of energy. It’s gonna take a lot of effort to transform how you do software development.

    And you really want to pick the changes that are gonna have the biggest impact on your business first off so you can create that positive momentum. I think if you just go down the path of doing DevOps without picking those things that will have the biggest impact, you’ll start doing it, you won’t see the benefits, and over time the organization will kind of disengage and you’ll lose momentum on your transformation.

    So a lot of what we focus on is trying to highlight those key lynchpins that you can really start making the big differences and how to go analyze that for different deployment pipelines in your organization.

    So it’s really that. I’ll be there. But there will also be a lot of your peers in the room. So it’ll be a good opportunity to take the things that you learned at Does to reflect on them and talk with myself and your peers about what you’re thinking about doing.

    And learning from it. And I would say that I’ve been doing this for a long time, and what I tell people is that just gives me more opportunities to have made the mistakes that you’re gonna make.

    And so if I can help you avoid the mistakes I already made so you can go make some new ones, learn from that, that’s kind of my goal. My experience is this stuff is such a breakthrough for the business that we’ve gotta have more people doing it. But how can we help people best we can so they realize those same benefits.

    Shimel: Excellent. Gary – you know, one of the things I think sometimes people get confused or question is when we talk about this is aimed at executives. It’s sort of a loaded term. In a large organization like a Macy’s, executive might mean CIO, it might mean VP of IT. in other organizations it may mean a director level. Can you give us a better definition or how you define you know, the executive who is gonna get a lot of good out of this workshop?

    Gruver: I think they all will. I’ve done it all the way from the CIO and I do execution workshops down to – to the leaders that are responsible for a tightly coupled deployment pipeline and then some organizations that might be a director or senior manager that’s over development and ideally, it’s nice that you can bring your partners in QA if it’s separate, and in operations if it’s separate. Maybe your security people, maybe your audit people.

    And come together as a team after Does. So if you’ve got a group of people that have gone to it and gone to a lot of different presentations, having them come together on that will be helpful. So this is the group at whatever level in the organization you think will be leading the transformation, or driving the changes. It can be – typically the CIO when I do the executive workshop is more to inform them of their role in it. Then at some level, we get down to a specific deployment pipeline.

    And the deployment pipeline may still be 1000 people if you’ve got a large tightly coupled system, like we had at Macy’s.

    Which requires large numbers of people working together, or it may be small. And if it’s small, you can do a lot of the things that you’ve seen unicorns do. And if it’s larger, the same principles apply but the practices are a little bit different.

    Shimel: Excellent. Yup. Great. So guys, we’ve covered a lot of ground here. Let me do a quick review. Sam, what day is the workshop?

    Fell: The workshop is the day directly after DevOps enterprise summit. Wednesday June 27.

    Shimel: It’s June 27.

    Fell: That’s correct. Right before… DevSecOps days on the 28th!

    Shimel: Yes, and Sam – I will put in our show notes a link to the URL about the workshop and registration. But where is it being held specifically?

    Fell: It’s conveniently located in exactly the same location as the DevOps Enterprise Summit which is the InterContinental – O2 in London. So if you’re in London, very convenient area to get to also. So come on by.

    Shimel: Excellent.

    Gruver: And you don’t have to have gone to DOES or the DevSecOps. If you’re in Europe and you wanted to stop by.

    Shimel: Excellent point. It’s not a pre-req if you’re looking for some good, hands on DevOps training and networking and education, this workshop is a standalone event. It’s fantastic as well. So let’s cover the three different workshops actually being conducted that day though. Number one is we’ve got none other than John Willis himself leading a real hands-on DevSecOps. Is Anders working with John on that one, Sam?

    Fell: Anders will be in there, yeah, he’ll be hanging around. But this is really John’s show. And this is his passion. And he’s driving the technical aspects of this workshop where people are really gonna be able to get their hands dirty with the technology, have a pipeline. Put some vulnerable code through it, and deploy it and then figure out how do we put automated steps in place and how do we sort of put the – get the developers thinking the right way to make sure that that kind of stuff can happen and what are the practices that need to be put in place. So really, for folks who want to try and get that level of specificity of how to do it, not just the high level, interesting, interesting workshop for people.

    Shimel: Absolutely. We’re all hearing a lot about DevSecOps. Gary made reference to DevSecOps. I think Helen did as well. And we talk about this DevSecOps rugged DevOps etc. This is really gonna be hands on. so it’s great whether you’re a DevOps person or a security person. Then we have Helen who is delivering the pre-req 101 DevOps essentials, based on the latest upcoming version of DevOps foundation from the DevOps Institute. And Helen, people who take essentials – do they get any kind of credit or anything towards a foundation or being able to take a certification or anything like that?

    Beal: As you said earlier, it’s basically a cut down version of the DevOps foundation course and that’s a certified course. This isn’t a certified course, so I’m sure if people wanted to follow up with the DevOps foundation, we could sort something out.

    Shimel: Fantastic. And then certainly, last but not least, aimed at DevOps leaders and executives, Gary is gonna be in essence, delivering what many organizations are paying thousands and thousands of dollars for. His course on kind of leading the transformation. That’s taken right from one of your books, Gary. I apologize. But really, dollar for dollar, what a great line up, what a great deal for anyone who is looking for DevOps training and education. I also wanted to quickly before we run out of time here, I wanted to mention that the day after the workshop is the first DevSecOps days in London.

    Again, headlined with John Willis. I think, Helen, you’re speaking there as well. Correct?

    Beal: I am, indeed. Yes.

    Shimel: Give us a little preview, what are you talking about?

    Beal: So John saw a talk I think I did in Belfast or somewhere – maybe last year. It might have been all day DevOps, can’t remember. Anyway. But basically we’ll be talking about DevSecOps engineering as a concept. As you probably know, the DOI at DevOps institute is just about to release a new course for DevSecOps engineering. So we’ll be talking about that role and what the requirements are to be successful in that area.

    Shimel: Yup. And DevSecOps days also promises to be a fantastic day. Sam and the Electric Cloud folks – we’re grateful for your sponsorship. Electric Cloud is one of the sponsors there. I will put in the show notes where you can get more information on DevSecOps days as well. But you can go to DevSecOpsdays.com and that’s the long and short of it right there. Guys, a couple of minutes left, let’s wrap up.

    Helen – beyond all of the great stuff you’re doing with DevOps institute, what any good news? Any new things going on with Ranger Four?

    Beal: One of the nice popular things that we’re doing at the moment is one of my favorite things conveniently as well. Which is our version of Phoenix project simulation game. That we kind of developed with our partner Gaming Works out in Amsterdam. So it’s a one day business simulation so experiential learning rather than classroom learning. We’ve got a free, public version of that coming up in London on the 19th of July. It is quite close to being fully booked.

    But if people want to find me on Linked In or would like to come along, we do have a couple of spaces left.

    Shimel: Excellent. And I’ve done the Phoenix Project simulation game, I love it and I’m sure you guys will deliver a rousing version, highly recommend. Gary, how about you?

    Gruver: Oh, I’m just spending more of my time with individual companies, learning from their journeys and trying to help them avoid the mistakes I’ve made and help them to learn from new mistakes they’re finding so I can help point it out to other people so that people can accelerate their journeys and be more successful. So that’s where I spend most of my time is just coaching different teams that are trying to transform their software development delivery processes.

    Shimel: You know what, Gary – what we should have mentioned though – for maybe folks listening out there who may want to engage your team to help them, where do they get information?

    Gruver: They can just go to garygruther.com – my website. And they can also go there and download a free copy of my latest starting scaling DevOps and enterprise, the electronic copies are there. I self-published that so I can give it away. Authors don’t really make money on books. So it’s out there, so I can give it away.

    If you read the first three chapters and then click at the end, you can get the rest of the chapters if you just give me your name, your title, where you work and where you live so that if I happen to be in the region – I keep thinking I’ll use that as a marketing tool. I haven’t sent anything out to it yet, but I’m still collecting names of the people that read the book because it feels like a good contact for me.

    Shimel: And of course, you’ve updated your privacy regulations to be GDPR. Anyway, Sam let’s see – DOES – you guys are the founding partners of DOES, you’re doing these workshop, you’re helping us with sponsoring DevSecOps days. What are you doing in your spare time?

    Fell: Next week we’re gonna be at Velocity San Jose if anybody is in the area, we’d love to have you stop by and see us. Yeah, we’re just looking forward to seeing everybody out in London. And it’s gonna be a super fun filled week. I mean, it’s a whole week of DevOps. I could not be happier. I’m super excited about it. really appreciate all the work that everybody is doing to try and make this community event a success. And looking forward to being in London.

    Shimel: As am I. I will be at all three of these events as well and you hit it there, Sam. Both the workshop and DevSecOps, these are community events. London has a fantastic DevOps community. Looking for your support, and I think it’s gonna be a great week for DevOps. So with that being said I think we’re about out of time here. Helen – as always it’s a pleasure to hear your voice and have you on the show with us. Look forward to seeing you in person.

    Gary, always a pleasure, my friend. I’m sorry, Helen – I stepped on you there.

    Beal: I was just gonna say, thank you very much for having me on and really looking forward to seeing you guys as well.

    Shimel: Great. Gary – as always, a pleasure.

    Gruver: It’s always a pleasure to get a chance to speak with you, Alan, and look forward to helping out the DevOps community.

    Shimel: Very cool – and Sam, what can I say that hasn’t already been said?

    Fell: I don’t know. You could say “goodbye?”

    Shimel: Okay – in that case, goodbye. This is Alan Shimel. You’ve just listened to another DevOps Chat. See you all in London for DevOps week.

    — Alan Shimel

  • DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    A great new book on DevOps is coming out called “The Kitty Hawk Venture.” In the vein of “The Phoenix Project,” it is a novel about one fictional company’s journey specifically with continuous testing. Based on a real-life airline company, the book is great case study and learning experience around continuous testing and its importance to the entire CI/CD and DevOps experience.

    The book is written by Jeff Schaeffer, general manager of the Continuous Testing business unit at CA Technologies; Alex Martin, CTO of Continuous Testing at CA Technologies (and former CTO of Rally Software); and Aruna Ravichandran, vice president of  Gobal Marketing at CA Technologies and author of “DevOps for Digital Leaders.” Beyond the book, there is a companion ebook on continuous testing, as well as other related content.

    In this DevOps Chat, we speak with Aruna, who is a frequent guest on our chats, about the book, continuous testing and the overall DevOps market. It is an excellent chat and, as usual, Aruna’s passion for what she does and DevOps shines through.

    For those not familiar with our DevOps Chats, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel. devopsy.kinsta.cloud. You’re listening to another DevOps chat. This is gonna be a really great chat. I have one of my dear friends in the DevOps industry joining us. Aruna Ravichandran Ravichandran, VP of Marketing DevOps at CA technologies. But more than that, now a multi-time author as well as a code engineer and a bunch of other things. She’s had an amazing, amazing life and career. Aruna Ravichandran, welcome.

    Aruna Ravichandran: Thank you, Alan. I am very excited to be here with you today talking about my latest book.

    Shimel: Yup. So it’s a new one coming out, hopefully in July I guess is the current timeline. And it’s called, “The Kitty Hawk Venture.”

    Ravichandran: That is exactly right. So you know, I think we chatted about a year ago when I wrote my first DevOps book. It was called, “DevOps for Digital Leaders.” And what we decided to do based upon the substance of the book is to basically to take a leaf from the Phoenix Project and write this book in terms of a real life story about one of our customers. I can’t name who the customer is. And the book is actually called, “The Kitty Hawk Venture.”

    And it’s a novel about continuous testing in the world of DevOps in order to help customers as they’re going through their digital transformation journey. So it’s not written as a continuous testing handbook.

    But it’s basically a real life example which happened with one of our customers and tells the story of the journey they actually went through in terms of how they actually transformed their testing discipline, lines of automation down to continuous testing and how they actually addressed some of the bigger challenges they actually had internally across the board.

    Shimel: Got it. So Aruna Ravichandran, I promised you and I promise our audience, no spoilers on this. So I don’t want to go too much into the actual story of the book, let’s keep it at a high level and say that it is about continuous testing and it is based on a real life customer experience. Maybe an amalgamation of customers.

    But you know, Aruna Ravichandran, you mentioned your first book, “DevOps for Digital Leaders.” So this is then your second book on DevOps.

    Ravichandran: Yes, it is. But this time I’ve actually focused on one of the emerging disciplines within DevOps. the first book was primarily focused around DevOps as a discipline, some of the challenges customers actually face.

    Where do they actually start. Because you know, there is no hard and fast rule in terms of DevOps. you can start with continuous integration. You could start with continuous operations. Or you could start with continuous testing.

    The book was primarily focused around end to end DevOps and gives some amount of coaching to the end reader on where to start, what’s the maturity model, what are some of the metrics, how do you measure the substance of DevOps.

    It also talks about several different customer examples on the journey they actually went through. But and speaking from that, we saw that a whole bunch of our readers are interested in learning more about an emerging discipline around continuous testing. So this book is primarily focused on continuous testing as a discipline and why it’s a very important area within the world of DevOps.

    Shimel: Yup. Now, Aruna , though, you hear it in your voice when you’re speaking to our audience here – it comes through loud and clear. this whole area of DevOps – continuous testing specifically with the book. It’s something that you are passionate about. I get it, you’re a VP in the DevOps group. You should feel an affinity. But this seems to go beyond your title and your job. It’s truly something you have a passion for.

    The book is almost 200 pages from the early view I saw. You don’t write 200 pages, you know, blah, blah, blah. You’ve gotta have sort of a burning passion. What is the passion that’s driving you?

    Ravichandran: So the passion that drives me is my customers. As I talk to my customers in the DevOps space, I am very passionate about solving customer problems. And as I talk to my customers, especially customers who want to make an impact, who are on their digital transformation journey, what I learned was testing is a discipline which has existed for several different decades across the board, the very first time when this actual code was actually implemented.

    But what you – what I actually found is that people have testing practices. But it’s mostly around islands of automation. Very, very few customers actually are doing end to end testing, which I call continuous testing.

    And even though you have islands of automation, what I actually find is that testing still continues to be manual. I did a poll of a whole bunch of enterprise customers across the board, and I was shocked to find that testing still appears to be 70% manual across the board.

    And given all of the – this is my personal reason for why I am very passionate about continuous testing, because I think that DevOps has gained a tremendous amount of precedent, but if you don’t embed continuous testing as a discipline across the software development life cycle, you really cannot go through DevOps.

    So continuous delivery has a lot of what do you say affiliation with the market. More and more people are getting educated on how to basically go through the CICD pipeline so that it can go from code to production in minutes. But what they realize is that if you don’t have the testing discipline embedded across the SCLC, going through the pipeline doesn’t buy you anything.

    And so that’s why this is a very important topic which I am very passionate about.

    Shimel: I mean, Aruna Ravichandran, on some level it’s almost – and I think I’ve heard you say this, continuous testing is almost the missing link. Right? In the continuous delivery, in the software development life cycle delivery chain. Right?

    For a lot of – you know what I mean? Companies, they focus on configuration management, on CICD, even on security. But that continuous testing is – it’s right there. It’s a lynchpin. The other thing I wanted to just quickly mention about it is continuous testing isn’t just a pre-delivery —

    Shimel: It’s truly continuous.

    Ravichandran: You nailed it. I would 100 percent agree with you on everything you stated. It is the missing link within DevOps. continuous testing is a practice of testing across every activity in the software development life cycle with the hope that you can uncover and fix unexpected behavior as soon as it’s ingested.

    So it’s about embedding testing as a fundamental and ongoing aspect of every activity through the application life cycle, going all the way from requirements down into production, while facilitating the pre-exact mechanisms what happens in the world of DevOps to where you can actually fix the problem throughout the life cycle.

    Shimel: Let me return to “The Kitty Hawk (Venture),” here again if I can for a moment. You mentioned earlier you took a page out of Gene Kim’s Phoenix Project book in that this isn’t similar to other books you’ve written and that I’ve even reviewed. That are your typical sort of business textbooks, right? You follow an outline and a table of contents and it goes. “Kitty Hawk” is more like you say – a novel, I think is the right word for it.

    How does that make it different for the reader? Or the listener if it’s an audiobook? For someone reading the book.

    Ravichandran: Yup. So for example – this book “[The] Kitty Hawk Venture” is actually based on the main character in the book is Leigh Freemark and she’s a senior director for quality assurance at a company called Runway Air. So the vertical we actually chose was an airline company.

    The way this book is actually written is it talks about the journey of what they actually went through from a transformation journey. So they experienced a major glitch in terms of quality and which caused a substantial amount of negative reputation for Runway Air.

    So this book actually walks through Leigh’s journey, the journey of her own personal mission of making quality first as a big part of her agenda.

    And the way this book is written – we have so many technical books which basically come into the market on DevOps and on testing, so on and so forth. So we wanted to basically – we took a leaf from “The Phoenix Project,” and we also took another leaf from “The DevOps Handbook,” which is the second book which was recently announced by Gene Kim.

    So this is basically written as a novel which tells you the journey which Leigh Freemark went through with Runway Air, but at the end of each chapter we give guidance in technical terms, of what was the actual continuous testing journey Leigh actually went through.

    Right? So that’s why I said, it’s written as a novel but at the end of each chapter we also have like a handbook around the continuous testing discipline on what changes people actually need to make in order to fully embrace continuous testing as a discipline in the book.

    Shimel: And even beyond that, Aruna Ravichandran, from what I understand and correct me if I’m wrong, you guys are planning on coming out with sort of an eBook companion to “Kitty Hawk” on “The Definitive Guide for Continuous Testing.” Is that correct?

    Ravichandran: That is exactly right and so we just actually published it and it will be out very soon. It’s called “The Definitive Guide to Continuous Testing.” And here, we walk our users through 11 different disciplines on continuous testing.

    Ongoing all the way on small teams [sound drops] _____ to how basically they can go through the transformation journey on continuous testing. And at a very high level, I walk you through eleven disciplines and you will see that completely in the novel because that was the journey which Leigh Freeman actually went through in the book, is the first discipline how do you basically and it will – the – you know, all of your testers.

    It could be a developer who is actually doing unit testing or it could be someone who is doing API testing or it could be load testing. Or it could be reproduction testing. All testing in production, you need to be able to have your environment set up. How do you quickly virtualize your environment becomes a very important part of the mix.

    How do you basically break on your environment, how do you actually create your environments very, very quickly is one of the first disciplines. The second discipline talks about testing management right? So regardless of what testing you’re doing having the right data at the right time is very critical. So how quickly can you generate your data?

    And given the world of GDPR right now, you know, which basically went into a test in May, people have to be even more critical about generating test data. You want to make sure that your GDP are compliant. And so having the test data at the right time is critical but also being compliant with a whole bunch of mandates out there is even more critical. The third discipline talks about test automation. How do you basically fully orchestrate the application pipeline.

    So that if the scripts actually fail, you can orchestrate how you can actually achieve continuous testing. The fourth one is around pipeline orchestration. This is the backbone. Everything is tied to it. everything must be integrated with your entire automation stream. You need to understand how it works, how to interpret the results and how do you make quick decisions in order to find out which part of testing is actually a bottleneck?

    And this is what we actually call pipeline authorization. The fifth one focuses on the various different competences, right? If you are testing, the world is going more towards an API economy. So how do you actually bring API testing discipline so that you reduce the reliance on UI testing? Especially for business logic testing.

    The sixth one is around performance and load testing. Right? So you can’t think about performance and load testing toward the end of the testing life cycle. You need to think about shifting left performance and load testing so that you can enable development teams to actually think about this much more earlier on.

    The seventh one is the around the new emerging practice around security testing. So this is where everybody talks about DevSecOps, it’s all about shift left security. How do you enable developers to actually embed static code analysis as a part of their unit testing?

    How do you basically get them to think about security testing by making it easy for them? By having it integrated as a part of their ID environments, whether it’s intelliga or it’s xless or visual studios, so on and so forth. So security testing is the seventh one.

    The eighth one is accidents of test driven development and behavior-driven development. So you take the accidents criteria for each user and create that to ensure that those were actually met. Right? So this keeps testing focused within sprints and ensures developers develop what the business actually expect.

    The ninth one is around automated test generation. And this is the activity of manually designing and writing manual tests of automated tests which is the biggest bottleneck.

    They are the computing magazine data surveyed very recently and they asked, which is the biggest bottleneck across your software development life cycle? 63% of the practitioners actually said that testing was a bottleneck. And why was testing a bottleneck? Because it takes time.

    Think about it, you have actually created 200 test cases for your regression suite for a vertical feature you are going to launch. Let’s assume you’ve caught a major defect and you fix the vertical defect, it means that you have to go back and recreate all of your regression text suites.

    And if there was an automated way that you could take your requirements and as things changed in production you can recreate your test suite, that will be a tremendous amount of savings for anybody to actually not have to create the test cases manually which then eliminates the bottleneck which we actually have.

    The tenth one is around requirement engineering. You must include all of SDLC stakeholders into your continuous testing journey. This means finding a better way to communicate and collaborate right from the requirements phase. The earlier one includes requirements engineering into continuous testing initiatives, the smoother that continuous testing journey will be. Because team members will be working with the same understanding right from the beginning.

    And the last but not least – the eleventh discipline talks about feedback loops. This is the heart and soul of DevOps, it still continues to be the heart and soul of continuous testing. These are critical to ensure that you can have successful continuous testing.

    Shimel: Excellent. You know, Aruna Ravichandran, sitting here looking – I want you to talk about quality, I don’t know if we have time. Maybe we’ll do it on another show. But the 11 disciplines, you did a great job laying them out here. I’m just wondering if someone listening says to themselves, oh my goodness, where do I begin? This is daunting. There is eleven of them. What is your advice to someone just starting out, listening in here – do I do eleven at all at the same time? What do I start with? What – do I take the path of least resistance? How do I get started with this?

    Ravichandran: So I break it up into six different areas, so this is a question you get asked for DevOps and you get asked the same question around continuous testing. So if I have to give guidance on techniques on how to actually adopt – it’s also a cultural transformation too.

    So the first one is, you know, you need to figure out a way to improve the relationship between the tester and each developer. So keeping the team small and creating inter-team collaboration makes it very easy to actually report and actually share the results between the tester and developer.

    So that would be one important tactic which needs to be adopted from a cultural transformation perspective. Number two, is like I said, people actually have automation within testing, which is what we call test automation. But they really haven’t automated the whole thing. So I would say continue to make automation a priority.

    So figure out where people are spending a lot of their time – it could be around building a regression test suite, because they tend to be manual. So how do you automate? So keeping that automation mindset is important. Figuring out where you’re spending cycles of your time in terms of doing manual tasks is important. So making automation a priority is important.

    Map out within your SDLC and identify your automation opportunity. Number three is make it small – right? Like get small. Break it down into smaller increments so that it’s easier to test after every aspect of the SDLC. So break down increments after coding. Break it after design. This makes it easier to automate the test and it also makes it much more easy to deploy and integrate as a part of continuous delivery.

    The fourth one is you want to keep track of everything. Use metrics. Start-up criteria. Right? So your defect density rate is high, figure out how can you reduce the defect density rate. Continuous testing is all about immediately identifying if things are working or not. How do you basically rinse and repeat if it’s working, or how do you actually pivot and change if it’s actually not working.

    The fifth one is getting the right continuous testing tools. Tools play a big role. So we talked about also transformation, we talked about processes and practices, and also having the right tools is important. Figure out the tools that help you develop tests and analyze continuously.

    Pick the best of breed tools that work together in a way that incorporates very easily into your continuous delivery environment. Choose tools which have community based support, that have open source plans that everyone shares the challenges and solutions and have interesting and lead to interesting use cases.

    And last but not least, the number sixth one, is develop a system to display your results. So do deep dives into the results, because that shows you that if you have your code not working, where the gaps are. define your KPI and your acceptance criteria and make them quantifiable. Create dashboards to track those KPIs, including a baseline so that you can actually track with the sequence changes. So these are some of the disciplines I always share with my customers as well as my clients.

    Shimel: Excellent. And now with everyone listening on here. Aruna Ravichandran we’re almost out of time, one more question if you have a second.

    Ravichandran: Absolutely. I do.

    Shimel: So I don’t know if we’re letting the cat out of the bag. If you can’t talk about it, politely say so. But you’re about to roll out something we hear called continuous testing academy? Launching this summer?

    Ravichandran: Yup.

    Shimel: So what’s that about?

    Ravichandran: So the key thing – going back to the question you asked, this continuous testing is like an emerging discipline. People want to know what do I need to do, how do I need to start? How do I get there. And so last year I launched the – I saw that there was a tremendous amount of need in the market around JMeter.

    And so I launched JMeter academy in order to basically to provide input to the community so they could actually train themselves on JMeter. But this year, knowing that continuous testing is gaining tremendous amount of momentum, I’m going to launch a continuous testing academy.

    This is going to have a basic module, it will also have an advanced module. And people will actually have the opportunity to go through the entire module and get themselves certified. We’re also going to launch a certification and you will have the opportunity to become continuous testing certified by DevOps institute. So this is our way to give back to the community in order to basically get people understanding on how they need to evolve their continuous testing practice in order to make a bigger impact in the DevOps world.

    Shimel: Excellent, again, Aruna Ravichandran – great job. You are just, I mean, literally, what a dynamo. All over the place. Doing so many different projects. All with DevOps and continuous testing as a theme there. Congratulations and hats off to you. One of my heroes. Anyway, we’re about out of time. Thank you so much, Aruna Ravichandran, for giving us a preview. Once Kitty Hawk is available to the public, I’d love to have you back on and perhaps we can chat more about it, sound good?

    Ravichandran: Yep. That sounds awesome. As always, Alan, it was excellent talking to you. I love your energy, I love your passion. And looking forward to partnering with you more as we basically enable our customers and prospects to continue on marching further along in the world of DevOps.

    Shimel: Well stay tuned for some announcements, we’re working on it. Aruna Ravichandran, I will be in touch. Aruna Ravichandran Ravichandran, a VP product marketing, marketing DevOps, CA technology, multiple times author, and really DevOps enthusiast. Thank you for being our guest on DevOps chats today. We’ll speak to you soon. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • 10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    The DevOps and open source communities have been in a tizzy all week over the massive $7.5 billion Microsoft acquisition of GitHub. Even as many developers rage on Twitter about the deal and still others are rushing to migrate their repositories to alternative solutions—#movetogitlab has trended heavy this week—for the most part the DevOps community is taking it in stride. As devopsy.kinsta.cloud’s Don MacVittie explained, complaining or planning a move away from GitHub solely due to long-held grudges against Microsoft seems pretty counterproductive at the moment.

    He’s not alone. A lot of developers, evangelists, CTOs and other GitHub users out there doing the work that drives applications into production are looking at this as a potentially great thing. Others are more cautious, but at least believe this won’t set the movement backward. We’ve gathered a few thoughts from these professionals to help balance out the dialogue.

    Ensures GitHub Viability

    “For those developers that may be anxious and thinking about jumping ship, I am sure they also must realize the hard truth that for GitHub to succeed moving forward it needed an influx of cash. Inevitably, there would come a point where GitHub would need to start to actually turn a profit, something it has yet to achieve, before it would have to shut its doors. ”

    —Adam Mansfield, Microsoft practice leader at UpperEdge

    Provides Much-Needed Leadership

    “Satya Nadella has so far done a great job dropping the Windows religion to embrace the reality of the iOS, Android, Linux and multi-cloud world, which he will hopefully continue with the GitHub community. By putting Nat Friedman—former CEO & co-founder of Xamarin—in place as a technical CEO, Microsoft is sending a clear message that they’re committed to GitHub and the larger developer ecosystem.”

    —Jyoti Bansal, former CEO of AppDynamics and current co-founder of DevOps platform Harness

    GitHub Champions in Enterprise Have Easier Sell

    “For one, I wouldn’t be surprised if we start to see corporate firewalls allowing access to GitHub now that it’s a Microsoft owned property, and perhaps considered ‘enterprise-ready.’ Microsoft knows how to make products that make enterprise architects feel confident, so their blessing and ownership of GitHub could really encourage social coding within enterprise organizations.”

    —Matt Stratton, DevOps evangelist at PagerDuty

    Net Neutral Immediate Impact

    “Developers should not be anxious about this acquisition nor should they be excited. I honestly think this is an ‘oh well’ moment. Unless Microsoft has some crazy plan to sunset features or support for one vendor or another, everything should behave as business as usual for the foreseeable future. The only thing developers should watch is license fees and terms and conditions. Expect Microsoft to monetize the solution better in the coming months and potentially tie usage into MSDN.”

    —Morey Haber, CTO of BeyondTrust

    GitHub Already Had Its Own Problems

    “GitHub is not strong in this area (DevOps) and never has been; maybe if Microsoft made it easy to deploy to Azure it could be seen as an improvement. As a tangent, GitLab which is now the attractive alternative, has its own CI/CD tooling and can also be self-hosted for free. This is a major advantage over GitHub, and I’m wondering if corporate America will start looking more closely to the FOSS alternative to GitHub Enterprise.”

    —Mitch Pirtle, longtime developer and consultant at SpaceMonkeyLabs, former Tech Fellow at Capital One

    Opens Eyes for About Dangers of Centralization

    ” My hope is that – one way or another – this leads to greater competition, more innovation, and less reliance on any one single platform. I don’t feel that centralization around any one platform is good for the DevOps and FOSS communities. I also don’t feel consolidation to larger companies is a good thing, as it creates conflicts of interest and generally a lack of innovation. This consolidation could result in a more decentralized approach to both software development and DevOps integration, which will hopefully drive more innovation. I think that could ultimately be a positive outcome of this acquisition.”

    —Jeremy Steinert, CTO of WSM International

    Expect Better Integration for More Seamless CI/CD

    “Longer term, I expect GitHub’s integration with Azure to expand substantially, enabling some truly exciting developments for one-click code deployment to a Cloud infrastructure. DevOps for smaller companies will gain easier access to Azure resources. For DevOps as a whole, we will see acceleration of seamless code management within the context of actual deployment to containers. DevOps for enterprise has the greatest potential for improvement with this deal. There will be massive investment in improving developer interactions between infrastructure and code.”

    —Clint Wilson, VP of product management at DigiCert

    Here Come Better Enterprise DevOps Features

    “While I think the development community will have mixed emotions about the news, ultimately this is a massively positive moment for GitHub. GitHub is at the center of the developer community, but as a business, they have faced challenges in reaching the enterprise buyer—something Microsoft is extremely well-versed in. With Microsoft’s resources and expertise, GitHub no longer has to wrestle with the internal struggle of being open to the community and being open for businesses, ie. selling to the enterprise. Assuming it’s kept a separate entity and is not beholden exclusively to Azure, this acquisition gives GitHub the opportunity to deliver the features enterprise DevOps and development teams need.”

    —Tal Weiss, co-founder and CTO of OverOps

    Accelerates GitHub’s Servicing of DevOps Market

    “The new Microsoft is not the bogey of the past — VS Code is great; TypeScript is terrific; Microsoft has not merely accepted open source, but become an open source leader through its GitHub contributions. From a business perspective, I think the deal will pay off. Unlike competitors such as IBM and Oracle, Microsoft not only understands developers, but has a proven ability to sell to the SMB as well as to the enterprise market. Microsoft can probably grow the GitHub business substantially by executing better on GitHub’s existing strategic objectives, such as GitHub Enterprise, without alienating users. It may also be able to create significant value by applying its AI technology and VS Code innovation to GitHub’s enormous corpus of code.

    —Rod Johnson, co-founder and CEO of Atomist and creator of Spring

    Validates Value of What Open Source and Devs Do

    “I think overall this is good for the DevOps movement, and open source in general. It’s a very strong validation of how important open source is not just to open source developers, but also the business world. Developers have a right to be anxious, but there are many viable options for open source hosting in this day and age, so if Microsoft does not prove to be a good steward of GitHub, they have other options. However, Microsoft could very well keep GitHub going.”

    —Logan Abbott, president of SourceForge.net

    — Ericka Chickowski