devopsy.kinsta.cloud

Category: CloudBees

  • Work from Home Tips

    Work from Home Tips

    Bees have worked remotely since our founding 10 years ago. We have an internal Slack channel used to discuss topics related to working from home. We threw out a question or two, asking the Bees for their best tips and practices to make working from home easier. We got back a ton of responses and wanted to share them with you.

    Do you have any tips of your own to share? Push them out on Twitter and tag us (@CloudBees ). We will select a few to add to this blog!

    Tips and best practices from CloudBees employees:

    COMMUNICATION

    “Send ‘Good morning’ and ‘Have a good night’ chats to the team. You would say good morning to your colleagues when you come into the office so why wouldn’t you still do that when WFH? It informs your team you are online and available or you are done for the day.”
    – Nicole Case, HR Business Partner

    “Create a culture of embracing the distractions of working remote: I can’t tell you how many times seeing someone’s pet or child photobomb a video call is the highlight of the meeting vs. a negative distraction. It puts everyone in a better mood and at ease, knowing that home life distractions are inevitable and are part of this working arrangement.”
    – Nick Rendall, Product Marketing Manager

    “Provide channels that facilitate human bonds…or animal and baby bonds in our case. We have Slack channels for #social-cats, #social-dogs and #social-baBEES. Nothing like the smiling dogs or sweet potato covered babies of your co-workers to brighten your day.”
    – Kristin Baskett, Product Marketing Manager

    “Invest in the gear to work well, remotely. Lots of options here, but doing your best to increase the fidelity of online interactions makes a massive difference in how you are perceived, both internally and to customers (if you interact with them). Even marginal increases in the quality of your interactions matter. Replacing in-person communication is hard, but very possible. This takes consideration and effort.”
    – Kenny Younger, Senior DevOps Consultant

    “Communication tools are not only for talking about tasks, but also for socializing. If I feel depressed or I am just not in the mood, I have work pauses and talk with my fellow team members. Creating relationships is even more important when you work from home.
    – Raul Arabaolaza, Software Engineer

    YOUR WORK SPACE

    “I have a break area setup when I work from home and it is located in another room so I have to get up and move away from the computer. I typically have a jigsaw puzzle that I work on for about 20-30 minutes. It forces me to stop working and shut my brain off from the last meeting. Also, I like to change things in my background to see who’s paying attention on camera. It sort of helps gauge who is watching and listening to me.”
    – Melissa McClure, Manager, Corporate Programs

    “A dedicated home office space is key to being productive at home. It will help reduce the necessary ‘context switching’ that comes with disruptions. If you don’t have a home office and your kids have a desk in their room, use that until they get home from school. Just be mindful that on video conference calls those Hello Kitty and Ant Man posters will be in the background. But they’re a great way to break the ice and relax with your colleagues or customers. We’re all human – celebrate it.”
    – Tim Johnson, Product Marketing Manager

    “Make a room of your home the workplace – preferably with a closing door. I have a makeshift kitchenette in my office with coffee, water cooler, snacks, mini-fridge. Even though the kitchen is just steps away, leaving ‘work’ disrupts your flow state. On the same note, when work is done you can really leave it behind that door. That’s harder to do mentally if you are working at the kitchen table or on the couch.”
    – Kristin Baskett, Product Marketing Manager

    “I have been doing it full-time since 2005 and the tips I have are:

    • Write well
    • Have your own real office space
    • Have two kinds of Internet connections available
    • Don’t work in pyjamas, wear normal clothes
    • Start out with regular timeframes and don’t relax it until you have been working that way for years”

    – Michael Neale, M&A Strategy Director

    “Have a space dedicated to work, and only work there. Do not have things in that space (or visible) that trigger, even subconsciously, non-work stuff. If you can, dedicating a room, or cordoned off portion of a room, is ideal.
    – Kenny Younger, Senior DevOps Consultant

    YOUR MENTAL HEALTH

    “What I found to be the most beneficial when I pivoted to remote work was still getting dressed and ready for work. Even if it’s only work from the waist up, once I gear up my head is in the game.”
    – Rose Becerra, Product Manager

    “Discipline is key. Stay strong and stay on your schedule. Be sure to keep up with exercise, shower, brush your teeth, comb your hair (for those of you that have it) and put on your work clothes. If you dress the part, you will feel the part, you will act the part and will inspire a response from colleagues and customers.”
    – Matt Cillis, VP, North America Sales

    “You need a balance between flexibility and predictability in your working hours to take full advantage of working at home, I usually do most of my work at office hours but I keep my starting and ending time flexible.”
    – Raul Arabaolaza, Software Engineer

    “Time box work. Take a “commute” to and from work each day. Put on your hat when you “leave” home and put it away when you “arrive” later. You have to separate your mind from work to be present at home. This is not only healthy for home life, it’s healthy for your work. You need to take rest from work to do quality work.
    – Kenny Younger, Senior DevOps Consultant

    “On quiet days, when I only have a few minutes of calls, if I am not doing a really mentally challenging task, I like to put some podcasts or YouTube videos in the background. Most of the time I don’t pay attention to them, but I like hearing the voices in the background.”
    – Esther Alvarez Feijoo, Software Engineer

    “There are some meetings that you can have while walking in the garden or any quiet place. It is relaxing and at the same time, healthier.”
    – Raul Arabaolaza, Software Engineer

    “Track your working hours, it’s easy to work more than usual and you need to balance.
    – Raul Arabaolaza, Software Engineer

    “You need a balance between flexibility and predictability in your work hours to take full advantage of working from home. I usually do most of my work during office hours, but I keep my starting and ending times flexible.”
    – Raul Arabaolaza, Software Engineer

    YOUR CHILDREN

    “I saw a posting on Reddit for creating a sane home environment in which kids do chores/homework/exercise to earn privileges for things that want to do (video games, shows, soda). We use monopoly money, not real currency. Day three and its working well with Logan (12 years, boy), Lucca (10 years, boy), and Lilah (7 years, girl)…after the initial resistance.”
    – Michael Bevilacqua, Chief Architect

    “In addition to corporate America suggesting we work from home, some of our schools are now shutting down; so our kids will be with us…at home…all….day…long. If you have young kids, I recommend jointly setting a schedule that includes both playtime and learning time. Have them work on math problems for 30 minutes, then history for 30 minutes, and yes, there’s probably going to be quiet movie time when you’re on that important video conference call.”
    – Todd Stayin*, Senior Customer Success Manager
    *Yes. His real name!

    “Don’t get too rigid with start and finish, there is nothing wrong if you stop one hour in the middle of the afternoon to play with your kids and work back after dinner. But remember the previous point about tracking hours.
    – Raul Arabaolaza, Software Engineer

    PHYSICAL HEALTH

    “I need the dog-walking breaks to keep me sane. When the dog cannot go out (sick, whatever), I can feel it within two days.”
    – Eduardo Pelegri-Llopart, Architect

    “Be sure to take breaks – when you are in the office and have interactions with others you get a break (i.e. get coffee, chat with co-workers about non-work things, etc.) but when you are home alone you don’t get those breaks. Be sure to get up, take a short walk or stretch, it’s good for both the body and the mind.”
    – Noel Seaton, Customer Enablement

    “This is probably only useful for me, but fridge visits are allowed just once in the morning and only to take fresh fruit.
    – Raul Arabaolaza, Software Engineer

    “WFH for 10 years – if I don’t get out (cycling) and see real humans (I don’t include family there – LOL!) I start to go a bit insane after about three days (e.g. during the rainy season). This is not great for the current crisis – I am pondering using Zwift and online cycling as a stopgap measure.”
    – Ben Walding, Director, Engineering Operations

    Additional Resources for Coping With COVID-19

  • DevOps Chat: ASG State of Software Delivery Management Report

    DevOps Chat: ASG State of Software Delivery Management Report

    Accelerated Strategies Group has just delivered its “State of Software Delivery Management Report,” commissioned by CloudBees. In this DevOps Chat, we speak with Mitchell Ashley, CEO, founder of ASG, about the report and why it is important for everyone managing software delivery today.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re listening to another DevOps Chat. I have a really great chat lined up for us today because I’m joined by my partner, Mitchell Ashley, founder, CEO of Accelerated Strategies Group. Mitchell, welcome to another DevOps Chat.

    Mitchell Ashley: Well, very nice to be here. It’s great to be on this side of the microphone for a change. [Laughs]

    Shimel: It is kind of. I mean, Mitchell, before we jump into the report out of Accelerated Strategies Group we want to talk about, just as little history for our audience. Mitchell and I have been doing podcasts together now –

    Ashley: Oh my.

    Shimel: Fifteen years?

    Ashley: At least. 2004 or ’05, something like that. Yeah.

    Shimel: So it’s still secure after all these years.

    Ashley: I was waiting for the,”This is Alan Shimel and this is Mitchell Ashley.” [Laughs]

    Shimel: Exactly. Do you remember those days? Oh my goodness. You know what’s old’s new. It’s good to have you on with me, Mitchell. You know, as you said you’re often on this side. You and I kind of split up our hosting duties for DevOps Chat. But we’re here today because Accelerated Strategies Group just dropped a report on the state of software delivery management, SDM.

    Ashley: We did.

    Shimel: And the report was commissioned by our friends at CloudBees but it really is the independent analysis and research of you, Sanjeev Sharma, principal analyst at Accelerated Strategies Group, and the rest of the Accelerated Strategies team. So, you know, we’ve done a little video on this, Mitchell, but I’m going to assume our audience listening here on DevOps Chat maybe didn’t see the video.

    Ashley: Okay.

    Shimel: Why don’t we start off – when we talk about SDM, what are we talking about here?

    Ashley: You know, we used to – we’ve had all kinds of names for methodologies, you know, software development lifecycle management, blah, blah, blah. You know, what I think it’s really about, software delivery management is about the whole delivery, the end-to-end process of how do you manage the software process from here’s money, we’re going to invest in something that we think is going to be created through software; how do you know through the whole machinations it goes through to actually create the software that you know where you are and what you think you’re going to be getting? And then when it’s all done how do you know that you got what you thought you paid for? To think about is sort of as a business view into managing the software process.

    So not just IT and product teams but also the executives, senior leaders, can find out what the heck is going on and how well – it’s really about how well do we develop software and how well – our ability to manage it.

    Shimel: Yeah. I agree. You know, we had this discussion earlier with Sanjeev as well, correct, and, you know, in my mind it’s about how do we manage the factory rather than how do we work on the assembly line? A lot of software today, especially in the DevOps world, is about how do we work on the assembly line? And that’s a noble, worthy thing to do.

    Ashley: It’s important, yeah.

    Shimel: Right. That software delivery pipeline, that factory, you know, assembly line as we move software left to right. But, you know, someone needs to be managing the controls, right? And are we doing it just in time? Are we using lean? And if so, how? You know, even lean you always need to be turning a dial and checking things out.

    Ashley: Exactly.

    Shimel: I’d like to talk a little bit, Mitchell – well, let me – let’s first start with this.

    Ashley: Sure.

    Shimel: Of course the mantra at Accelerated Strategies is information wants to be free, and in that vein this report is free and open to anyone – anyone – who’d like to download it, right?

    Ashley: It is. That’s our belief. I mean that’s really what we founded and you were part of founding Accelerated Strategies group two, is let’s do something disruptive in the analyst industry. You and I have paid an awful lot of money to analysts for sometimes questionable [laughs] – what are we getting for it? – but we have to do it, right?

    Shimel: Well we paid for access.

    Ashley: We paid for access even though that’s – you know, everyone says it’s not true –

    Shimel: [Inaudible comment]

    Ashley: – but it is. I mean let’s be honest about it. I think it is anyway. With Accelerated we said, “Look, we’re not going to pay –” you know, every time you touch an analyst you had to pay him. Every time you said something to him you’re like dropping in another coin. And let’s do this the right way. Let’s do this – when you’re working with us, engaging us to do something for you, you know, do some research, assess the market, advise you, do a strategic project, do some competitive analysis, all of those things for a research report, that’s when we’ll make our money. You are welcome to distribute that as freely as you like.

    We’re not going to hold you behind a paywall and subscription fees and licensing. The customer’s give us all that information. Why don’t we give it back to them in some meaningful way [laughs] instead of making them pay for it? That’s –

    Shimel: You know what, Mitchell? I think back to the days where we would pay, you know, a certain large analyst company to send an analyst out to spend the day with us, and we’d pick them up at the airport and get them breakfast and lunch and, you know, keep – wine and dine them all day while trying to get him to understand our point of view, and when I drop him back off at the airport, I’ll be honest with you, I felt a little dirty.

    [Laughter]

    Ashley: And it kind of felt like, why do I feel like we know more about this space than the analyst?

    Shimel: Yeah, there was no doubt that I felt like I knew more about that space, but, you know – and I’m not – look, everybody needs to make a living and there’s the oldest professions in the world, but I really felt like I – I didn’t like paying for it. You know what I mean? And there was definitely some of that involved. But enough about the analysts. _____.

    Ashley: We could do, like, three podcast episodes on that or more.

    Shimel: Yeah. We can go off on that. What I want you to talk about though, Mitchell, is would you share with our audience a little bit of insight? How was the research done here, the analysis? I know Sanjeev Sharma, principle analyst, was lead author on this report, but give us an idea of, you know, the ASG methodology, if you will.

    Ashley: Well really any research has to start out with some hypothesis; what do we believe about the market or what do you think we believe about the market? And really the hypothesis here was around what’s the maturity level of our ability to manage the entire software delivery process? Connecting it to the business, not just inside of IT. So we started with that and we have a target audience who we’re trying to talk with, both individual contributors, leaders in the software development part of this but also executives, product people, CIOs. So we really tried to cast a big enough net but not so broad that it all got watered down and you couldn’t tell who said what.

    We really spent some time focusing on who we wanted to talk to. And it wasn’t a short survey but it wasn’t a long one. There were really some insightful questions around do you know what your backlog looks like and what it costs you to delay a release or to trade something off one feature for another? Do you really know when you’re going to get the release or the functionality that you’re paying for so you can move the business forward based on those plans, or are you kind of shooting in the dark and you’re just hoping that it comes out sometime in the next quarter and we’re good and then we’ll kind of get everything running from there? So we did a survey, but we did a lot of kind of research going into it, talking to different people in those roles before we ever built the questionnaire.

    So it’s not just a research firm that says, “Okay, what do you want us to ask? Let’s build you a survey.” You know, Sanjeev and the other analysts with Accelerated Strategies Group are all practitioners. They’ve done this, they’ve worked in this field, they’ve led software teams, projects, companies, they’ve consulted with big enterprises, small startups, medium-size companies. So all that to say it was really, you know, our best attempt at let’s get the best information we can when we go out and ask people for where they think they are with their maturity curve and where they really see the challenges, and we got some fantastic results. It was super, super insightful and kind of exciting to see, you know, what things we thought were true and what maybe some things were, hm, that’s a little bit of a surprise.

    Shimel: Yeah. Okay. I guess you kind of opened that box now.

    Ashley: Did I set it up well enough?

    Shimel: Yeah. I think you got it. So let’s start with the surprises.

    Ashley: You know, so one of the biggest things that everyone – I don’t want to say everyone – one of the biggest outcomes of this research was around everyone’s ability to understand the value they’re going to get from their investment, right? Spending how much money on this software IT organization, product team whatever, and what am I really going to get at the end? So it’s very clear it’s very unclear to the people funding the work, that they essentially understand what they’re going to get. You just can’t get to that information or get a straight answer.

    We aren’t connected well enough into it to really understand it, which kind of goes to the second key finding was the communications around the whole software creation process is broken. It may work within a development team that’s really functioning tightly together or an Agile team with a product leader that they’re working with day to day, but outside of that, both kind of horizontally but also vertically in the organization, the perception at senior leader levels versus the individual and the team levels that are building software can be much, much different. So can you imagine making – well, we’ve done this right, Alan? – making multimillion, maybe much, much, much larger decisions based on what you think is going on and that’s not really true.

    So that’s a huge issue. If we really believe in software is leading the world, that all businesses are software companies, you have to be – you’ve got to fix that. That’s got to be taken care of. And then the third area is basically all the way through the delivery pipeline and understanding the value flow. Where are you creating value and where are you actually spending energy and not getting value? Maybe getting the wrong output out of the software process. Because an example I like to use is software teams like to measure how many releases we get out per day, sometimes per hour. I mean that’s a great thing. It sounds like a really awesome thing to accomplish. But if it’s the wrong thing, wrong software, it doesn’t matter if we’re releasing it a million times an hour. I’ll take one release a month if it’s the right thing instead of a million releases every day and all of them aren’t hitting the mark.

    Shimel: Yeah, I agree.

    Ashley: That’s an extreme, but that’s really what it is, is understanding through that whole – and again, we’re talking about not one pipeline of work, one value stream of work; it’s across multiple, because almost every app touches all kinds of systems, data, you know, especially in a large enterprise – mainframe, stuff in the cloud, stuff that’s maybe kind of the older client server but still around, whatever it might be. So those are the three key areas that we identified that if you can assess where you are and how well you do that part of the software development, that will make the biggest difference in sort of upping your game and your ability to deliver software.

    Shimel: Agreed. Agreed. You know, I guess I’m not surprised but I am surprised in that, you know, the first thing I learned about DevOps was it’s about breaking down silos, bringing dev and ops together. We’re going to break those silos. Kind of like the Macintosh 1984 commercial, remember?

    Ashley: [Laughs] The girl and the hammer, yeah.

  • State of Software Delivery Management Report 2020

    State of Software Delivery Management Report 2020

    Accelerated Strategies Group conducted the State of Software Delivery Management 2020, surveying software delivery practitioners and key industry leaders to assess the current state of software delivery management (SDM) and examine the impact of SDM adoption as a capability. The primary research, commissioned by CloudBees, was published on Tuesday, July 21.

    The State of Software Delivery Management Report 2020 defined SDM as “a core competency for any organization or team responsible for delivering business value via software applications and systems.” The report studies the impact of SDM and how it helps organizations accelerate their digital transformation by providing the necessary tools to effectively and efficiently deliver software.

    The report identified three key SDM capabilities to help organizations increase their software delivery efficiency and effectiveness:

    • Organizations must quantify the impact of their investment in software delivery.
    • Organizations must enhance the ability of software delivery teams to communicate and collaborate.
    • SDM can provide end-to-end visibility into the value flow of their software delivery streams.

    Based on the results of the research, adopting SDM strategies can help mitigate major challenges faced by software delivery practitioners, IT management, product stakeholders and executive leadership, and improve an organization’s ability to deliver software in a lean and agile manner. SDM capabilities provide businesses the ability to effectively make decisions on where in the value stream to invest, and to quantify the impact of their investments.

    Download the State of Software Delivery Management 2020 to learn more about SDM and to get insights and access to all the data Accelerated Strategies Group gathered from one-on-one interviews with key industry experts.

  • Financial Services: Future Proofing Your Digital Transformation Strategy

    Financial Services: Future Proofing Your Digital Transformation Strategy

    The Financial Services: Future Proofing Your Digital Transformation Strategy virtual event will explore the state of development and DevOps in the finance industry, and how organizations can digitally transform their strategy in order to release new, compliant applications and safely adapt to change at any speed demanded by the business. The virtual event will take place on July 9 at 2:30 p.m. CEST (8:30 a.m. ET).

    CloudBees is bringing together a stellar line-up of thought leaders to discuss the impact of digital transformation in financial services, including:

    • Sacha Labourey, CEO of CloudBees
    • Jost Hoppermann, VP and principal analyst at Forrester
    • Chafin Bryant, software engineering manager at Capital One
    • Keith Blizard, SVP of public cloud services at Fidelity Investments

    The experts will discuss the challenges the financial services industry faces in adopting DevOps.

    At the Financial Services: Future Proofing Your Digital Transformation Strategy virtual event you will learn:

    • How to assure separation of duties and access controls without stifling innovation.
    • About Capital One’s DevOps success story and how they’ve tackled some of the unique challenges of CI/CD in the finance industry.
    • How to incorporate legacy and hybrid technology into your release trains and processes.
    • How to scale across geographies, teams, applications, regulations and environments – and still get the velocity and reliability expected by the business.
    • About Fidelity’s cloud transformation journey and CI/CD best practices.
    • How to build bridges across devs and ops; employees and contractors.

    Join the CloudBees community and learn how to future-proof your digital transformation strategy. To check out the agenda and to register, visit the Financial Services: Future Proofing Your Digital Transformation Strategy website.

  • CloudBees Connect Virtual Summit: Defining the Future of Software Development

    CloudBees Connect Virtual Summit: Defining the Future of Software Development

    CloudBees Connect Virtual Summit will bring together a global community of developers, CloudBees and Jenkins users, DevOps luminaries and continuous delivery experts for two full days of immersive learning, presented in a virtual reality environment. The event is scheduled to take place on May 19 at 11 a.m. EDT for North America, and on May 20 at 11 a.m. CET for the European audience.

    At CloudBees Connect, you will learn about the emerging trends and technologies shaping the future of software, including one of the most innovative trends in technology: continuous delivery. Continuous delivery allows you to deliver software faster and with lower risk, while preserving quality and reliability.

    Industry leaders will share their knowledge and expertise on CI/CD tools and best practices. You will learn how to successfully create a fully operational CD pipeline using containers, Kubernetes and Jenkins X; and how to automate security and privacy testing in your Jenkins CI/CD pipeline for continuous security.

    The event will consist of a series of workshops designed to provide great value to the attendees. Here are a few things you will learn by attending these workshops:

    • How your COBOL source code can be branched/merged/deployed using GitHub, CloudBees and Compuware tooling.
    • Best practices for continuously integrating code using CloudBees Core.
    • How to build and test applications using Jenkins Pipelines and Sauce Labs.
    • Solutions for the five most common Jenkins issues.
    • The role of feature flags in reducing risks associated with deployments.

    The workshops will feature a lineup of DevOps and continuous delivery leaders, including:

    • Oscar Medina, developer advocate at CloudBees
    • Viktor Farcic, Jenkins X product manager, principal software delivery strategist and developer advocate at CloudBees
    • Josh Grant, solution architect at Sauce Labs
    • Robert Kelley, director of delivery engineering at IHG
    • Stuart Ashby, DevOps specialist at Compuware
    • Alex Taylor, DevOps engineer at insightsoftware

    Discover what’s next from the CloudBees and Jenkins community, connect with industry experts and fellow developers, and get the skills and hands-on training you need in order to successfully deliver software.

    To check out the agenda, the full lineup of speakers and to register (for free), visit the CloudBees Connect website.

  • Software Development Management Drives Business Value

    Software Development Management Drives Business Value

    How much business value does your software group generate for your organization?

    That’s the existential question an international corporation’s software leader poses, kicking off the 2017 book “The Business Value of Software.” It’s also a topic we’ve all likely wrestled with from time to time. It’s the essence of the value we personally bring to the business through our daily actions.

    The problem is, value is hard to define and hard to measure. But, it’s easy to see how business value can seep away from software initiatives when software projects start to experience problems. 

    When production is delayed, and software releases don’t go out on time, sales will fall short of projections. When a release doesn’t satisfy customer needs in a specific market, negative user reviews will spike–and that could impact future sales. When market trends shift suddenly, and business unit leaders have no clear way to push the development team to add new features to the product, that’s a missed market opportunity.

    With every misstep, you’ve lost a certain amount of business value.

    Conceptually, every one of these situations is fixable. To an extent, some companies have adopted practices that can catch certain problems before they become unfixable. But, to a greater extent, the inability of software-driven companies to anticipate trends, flag problems, share information, iterate on solutions and learn from mistakes is costing them business.

    In this blog series, we’ve discussed how software delivery management (SDM) presents a framework for organizations to change the way they think about software and streamline delivery processes. SDM seeks to connect all aspects of the software delivery process to not only become more efficient but also drive toward a common goal of delivering maximum business value.

    The SDM model is built around four key pillars: ensuring everybody is working with common data; sharing insights and continuous learning across the organization; connecting processes to bring ideas to market; and enabling closer collaboration across software-related functions and teams to amplify value creation efforts. It emphasizes that software doesn’t have to go it alone–the whole organization is rallying around software and making it a top priority.

    How does an interconnected, collaborative, information-driven software organization create business value using SDM? Here are a few ways.

    Leaning on Analytics

    Rather than just using discrete build-test-deploy processes, make sure management, developers, marketers and engineers are all incorporating key analytical measures in their iteration processes. These stakeholders shouldn’t go on hunches–they should base their decisions, at least in part, on data. The data includes downloads, adoption figures, conversions, support requests and customer experience performance ratings. Armed with information, the organization will do a better job delivering the software customers want and are willing to pay for.

    Helping People Ask the Right Questions

    Developers are a prideful bunch. They want to build great software that users love to run. Without insight into business needs and user preferences, they’ll do their best with features and functionality. With data sharing and communications channels in place, they can ask questions like “Where is this feature being deployed?” or “Why will customers want a whole new interface?” Consequently, ops pros can ask, “Who pushed this new release to production and when?” VPs can ask whether the latest round of releases will be ready for the big marketing push to launch it. If you’re asking the right questions early enough in the process, you’re going to make better decisions and be doing a better job delivering on business goals.

    Being Nimble Enough to Change Quickly

    Organizations pride themselves by their ability to act in an agile manner. But, are they really set up to move on a dime? Say a well-researched release flops unexpectedly. Sales and support rapidly gather feedback that European users hate the color and APAC users hate the navigation path. Because all the stakeholders are aligned and ready to move, developers tweak the features, ops leaders juggle the release schedule, management relaunches with regional marketing campaigns, sales follows up with targeted incentives and developers watch for more user feedback that can be incorporated into future releases.

    Your company has worked hard to turn itself into a software-driven business. Using the principles of SDM, your business can drive business results to the next level. It can generate more sales. It can make unhappy customers happy. It can make happy customers even happier. It can improve its own responsiveness, up and down the organization. Most of all, it can use software to achieve its ultimate goal: to drive business value.

  • How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    Since Jez Humble and David Farley popularized the term in 2010, continuous delivery has revolutionized software delivery practices. 

    Creating mature continuous integration/continuous delivery (CI/CD) pipelines has helped enterprises deliver software that performs better, based on a long list of metrics. Failure rates have dropped from 50% to under 15%, and cycle times are measured in hours, not weeks. Organizations get to market faster and release products into production with fewer bugs.

    But, there’s a limit to what CI/CD can provide. CI/CD connects only the parts of the software lifecycle that happen inside DevOps. It doesn’t provide insights into where the delivery cycle is breaking down, whether the software is helping the business meet its internal key performance indicators (KPIs), how customers are responding to it or whether last week’s release is achieving the internal efficiencies the business was projecting.

    A More Holistic Approach

    This is where a more holistic approach to software delivery can help. As we discussed in a previous blog, there’s a move afoot to recognize software delivery as more of a core business process and connect all the aspects of this process in one new, interconnected discipline. 

    The new discipline, called software delivery management (SDM), changes the game by going beyond CI/CD and empowering developers and other stakeholders to best collaborate and creatively solve problems. It gives them the data, insights and best practices that allow them to truly continuously improve, keep value flowing and efficiently develop and deliver the right products and features to customers.

    To follow SDM principles, a management solution needs to rest upon four key pillars: common data, universal insights, common connected processes and having all functions collaborating.

    • Data: All information within and around software delivery activity would need to be captured and stored with a consistent domain model to enable and facilitate connected processes, shared insights and collaboration.
    • Insights: Visibility and insights would need to enable a common understanding and continuous learning from data across, up-and-down and throughout all functions in the organization.
    • Processes: Processes would need to orchestrate the entirety of the software delivery value stream and connect functions together to efficiently bring ideas to market with maximum value and adoption.
    • Collaboration: All functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.

    This holistic approach helps organizations in a number of ways. Here are three benefits DevOps managers can net in terms of the way they work, collaborate with development teams and connect with peers throughout their organizations.

    Faster Development

    The current process can be slow and tedious. Developers use tools configured to perform one task, and getting a complete end-to-end view across the toolchain is difficult. An SDM solution stores all the artifacts and data from disparate tools that move software from idea to deployment in a unified common data layer. The information is connected and available for those who need it, when they need it and in a form they can use. Just forging these connections will save hours of time looking for data, checking statuses and tracking issues throughout the delivery process. 

    Better Software

    If stakeholders have no end-to-end view of the development and delivery process, they have no way of knowing if the software is meeting the organization’s business objectives. With SDM, the continuous feedback loop established with CI/CD and DevOps is extended to fully include all stakeholders from the ideation phase through user adoption and back to ideation. Better insights are tracked more closely and shared more widely, helping developers do a better job of delivering what the users want.

    Better Collaboration

    Developers and business leaders don’t collaborate well for a number of reasons. Developers often don’t have a good feel for how a product is going to be used, and business leaders usually don’t have insight into what’s in development or when it will be delivered. This is complicated by scattershot communications processes–where both sides have to sort through spreadsheets, connect over email threads and wait for meetings to move processes forward. With SDM, the silos between the software organization and other stakeholders are broken down, so both sides can share information, communicate more directly and drive toward solutions. 

    In an upcoming blog, we’ll explore other examples of SDM in action and dive into the business value it creates for organizations.

  • Software Delivery Management: New Mindset

    Software Delivery Management: New Mindset

    Innovation and mindset can take a while to evolve. It was the case with social media, wireless communications and the Internet of Things.

    Software delivery is a good example of a concept that’s ready to stand on its own. As software becomes more integral to companies and to society at large, the way it’s designed, built and distributed has evolved. Today, the delivery process is far more sophisticated than it used to be, with more resources in the mix and more moving parts. After years of looking at aspects of the software delivery process as separate pieces, people are thinking differently about how all the pieces fit together.

    That change in thinking is putting momentum behind the creation of a new IT category called software delivery management (SDM). SDM pulls together under one umbrella all the teams, tools, information sources and processes that relate to the delivery of software. It aims to eliminate inefficiencies that have cropped up along the way and help create a more value-driven process, aligning organizations’ resources toward a common set of goals.

    The Road to SDM

    For decades people divided IT into two basic camps: hardware and software. The categories were analyzed largely in terms of output. Experts tracked how many computer boxes a big integrated manufacturer such as IBM or Digital Equipment Corp. made, or how many software disks Microsoft spun off its production lines. Companies had their own methods of getting products out the door. Management techniques such as TQM helped guide these processes, but little outside attention was paid to specific steps companies took along the way.

    All of this changed as software itself started to evolve. The internet, smartphones and more versatile operating systems opened up the software market to everybody. Software producers (manufacturers and individual companies alike) spent a lot of cycles working to perfect aspects of the software delivery process. Companies created teams to research, scope, develop, engineer, produce, integrate, test, market and sell software apps. They applied a variety of tools to accomplish specific tasks and implemented processes such as continuous integration and continuous delivery (CI/CD) to help streamline the engineering functions.

    These advancements brought software to where it is today—companies are delivering apps quickly and updating them often. Operations teams are collaborating with developers, and organizations are doing their best to anticipate customer needs and institute quality control mechanisms. Software is achieving things never thought possible.

    Stashed in Silos

    But the delivery process isn’t perfect. Too often, pieces are separated from each other. Tools don’t work together. Teams don’t talk to each other enough. Information is stashed in silos that one side of the organization isn’t sharing with another. Data that does get shared hasn’t been updated.

    Disconnects like these cause ripple effects throughout the organization. Projects get delayed; apps get delivered with bugs and/or vulnerabilities; developers find themselves overworked, restarting initiatives because they didn’t have the information they needed to do it right the first time. Executives get frustrated that teams aren’t delivering on their goals.

    The disconnects can’t really be blamed on a particular team, tool or misplaced plan. They’re the fault of the overall process itself. A development team might be doing a great job with a top-quality tool and a well-thought-out plan. But if the product development group supplied developers with out-of-date information and a testing tool doesn’t integrate with a tracking database, the project will run into problems.

    All Processes Connected

    What’s needed is a new category that looks at software delivery from a holistic vantage point. Everything connects with everything. SDM provides those connections. It outlines a set of pillars to unify data, insights, processes and functions—aligning organizations around a common set of goals.

    In upcoming blogs, we’ll look more closely at how SDM works, what kinds of benefits it can provide and how it can generate true business value for an organization.

    — Anders Wallgren

  • Broadridge’s Annie Michelia on Why DevOps and the Cloud Go Hand-In-Hand

    Broadridge’s Annie Michelia on Why DevOps and the Cloud Go Hand-In-Hand

    Brian Dawson: Hello. Welcome to DevOps Radio, live at DevOps World | Jenkins World 2019. I have the pleasure of having a chance to interview Annie Michelia. She is a database architect at Broadridge, and really not just a database architect. As we talked and as I understand your bio, you actually have a wide range of skills and it appears that you do a lot there at Broadridge. Can you start by telling us a bit about what you do and about how you arrived there?

    Annie Michelia: Yes. By trade, I’m an Oracle DBA, to start with. So I’ve been working as a database administrator for most of my professional life. Right now in Broadridge, I work as an architect, in the sense, I work with on-premise database technologies as well as AWS cloud technologies. So I play a major role in cloud initiative projects for lift and shifts. So that’s when the DevOps kicked in.

    Brian: Okay. While you’re there, can you tell me a bit about DevOps at Broadridge? You mentioned DevOps kicked in. I’m curious to know where you guys are on your DevOps journey in terms of Broadridge, and why you guys are pursuing it?

    Annie: That’s a good question. So we in Broadridge have been using DevOps practices for more than five years now, successfully, to do all the application deployments, infrastructure deployments seamlessly. So the database was always standing in the backbench because of its complexity, not just complexity. Also, the thing is we handle mission-critical business data, which is persistent data, which we cannot touch and play around with.

    Brian: Your systems of record that need to be maintained can’t break, right.

    Annie: True. We are a financial solutions company. So for financial services, the criticality plays a very high role. So that’s why it has been staying aside. So when we started the initiatives for the cloud, the management decision was they said everything has to flow through automation, so no manual deploys, no manual installs. So we started this initiative just for the cloud piece, so for the database side.

    Brian: Okay.

    Annie: So what we thought is whatever we did manually in the past for databases needs to be automated, not just infrastructure, but also the ongoing deployments.

    Brian: The delivery and the deployment portion of it.

    Annie: Exactly. So all the schema changes, code changes and data changes, everything has to be in a no-touch environment. So that’s when we started practicing DevOps for database.

    Brian: So DevOps and cloud went hand-in-hand for Broadridge.

    Annie: Exactly, yeah.

    Brian: Okay. What drove the decision to go to the cloud? Do you know? Was it cost, speed?

    Annie: That’s one of the reasons, also the technology. So we evolved. We don’t want to be using the old technologies. The other reason could be cost, because of the licensing for the traditional enterprise DMS’s. So that’s why the organization has made a decision to do a lift and shift of most of the applications to cloud. So when we moved to the cloud, the decision was made that the environment should be zero-touch.

    Brian: Okay. I’m going to want to drill into, in a moment, lift and shift, which people have different opinions and it has different meanings, and also, some of the challenges of really integrating data and traditional relational databases into a CI pipeline. But before we do, I’d like to ask have you seen benefits of DevOps so far? Is Broadridge benefiting? Are customers benefiting? If so, how?

    Annie: When we thought of this automation for databases, it was really, really scary because we are dealing with critical data. So it was taking, actually, quite a time to understand and to convince the customers for the automation piece. But the whole point, if you look around the process itself, the manual process took a lot of time, but not just the time. The process, when you see it in manual, it actually involved multi-team participation. So not just the time, not just the human errors or something like that, it took multiple technical people from various teams to do a simple deployment process.

    Normally, the DBAs are doing – most of the time, the product – I’m sorry. Most of the time, the production support DBAs, who are hired to do production support, end up doing deployments all the time. We are a quite large company, so we have a lot of applications to support. So rather than doing the real production support work, the DBAs ended up doing deployments all day and weekends.

    Brian: And that’s at the cost of both the DBAs and potentially production support is now lacking, potentially, and not as responsive, right?

    Annie: True, yeah. When it comes to automation, one real big drawback is doing the manual setup of deployment. There is no traceability for what we deployed and where we deployed. Did we do it in a test environment? Was it successful? Are we ready to do it in production? Can we go forward? So there is no traceability, so that creates a big chaos.

    So when you break all this stuff into the DevOps automation, you have a version-controlled deployment. So there is a big traceability, and you know what you do in test, which can be promoted to production or not. So that’s the biggest advantage I see as a DBA over other constraints like time and other things.

    Brian: Right. You gain efficiencies.

    Annie: Efficiency, reliability.

    Brian: Visibility, traceability, which is huge. Now, I cannot claim by any means to be a database expert. I will share, I spent a bunch of years in the game industry as a software engineer/programming, and I didn’t quite get the importance of databases, the science behind it, the complexity. As I moved into the other phase of my career, more focused around enterprise development, and began to spend more time in traditional databases, I realized how complex it can be. Something I learned there is really in that space there are a lot of manual controls into place.

    Annie: True, yeah.

    Brian: A lot of responsibility put in the experts’ hands, because traceability was not really built into the database updates and migration process.

    Annie: That’s a little bit different. For a simple deployment, multiple teams are dependent on it and everybody ought to be on the spot for installation, validation, and then verification. So in this automation process, with a push of a button in Jenkins, that’s how we put it together. Any nontechnical person can run this. So there is not DB involvement. There is no one’s involvement, not a development involvement or a service delivery team’s involvement. Any nontechnical person can push a button from Jenkins, which can do all the magic.

    Brian: Okay.

    Annie: It retrieves the artifact from source control, extracts, makes a SQL connection, executes. Before execution, if there is a requirement for database backup, pre-deployment backup, advance into it, it takes the backup and runs the deployment, creates the log file, publishes the logs to all the interested parties.

    Brian: Awesome.

    Annie: Just the push of a button. So Jenkins does all the magic.

    Brian: I always love to hear Jenkins doing all of the magic.

    Annie: Yeah. That’s the only tool we are using for this automation.

    Brian: I’m going to want to dig into the hows of how you did this. Again, before we shift, I have a precursor question. Are you seeing customer or business benefit from this process? I think the internal benefit is immense. We talked about productivity, visibility, traceability. Is there error reduction? Is there reduction of failure rates that are bettering the service for the customer?

    Annie: Exactly. When we do the same thing manually, the errors may not be huge or quantifiable, but the impact of even one error is huge because we are in the financial industry.

    Brian: Yes, right. It could be millions, billions of dollar error, one error in data.

    Annie: Exactly. So we are fined with the _____, so we’ll be fined or penalized. The penalty is really huge for a single mistake in a year. So we completely eradicated the incidents. That’s a bigger achievement I could see.

    Brian: So the DevOps automation provided more reliability, safety, and security for your customers.

    Annie: Yes.

    Brian: I bet if we were to measure blood pressure, it probably also lowered blood pressure for the DBAs and team members.

    Annie: That is true, yeah.

    Brian: So let’s talk a bit about the technical implementation. Look, I’ll admit that oftentimes when we talk about DevOps and how to implement DevOps, there are some rough edges and some difficult areas that oftentimes the luminaries, evangelists, speakers tend to sort of gloss over. Security is one of those that isn’t fully integrated. Oftentimes, it’s difficult. Management of environments has improved considerably. But data is one that I think people still struggle with.

    Now, you guys chose to lift and shift. What I’ve seen a lot of greenfield teams do is sort of move directly to cloud technology, move directly to NoSQL databases, possibly do some level of ETL, but largely say, “We’re going to take our traditional data store and leave it behind because it’s so difficult.” You guys chose to lift and shift and bring along the data in the databases that you had invested in, correct?

    Annie: Correct.

    Brian: It sounds like it was challenging.

    Annie: It’s a challenge, but when you look at the organization’s perspective, the total infrastructure maintenance cost is completely removed or eradicated. So the technical people can spend more of their time on architecting things, rather than sitting and supporting things, the traditional work. So it’s just we are losing the job, but the nature of the job has been elevated.

    Brian: Right. You can focus on things that matter.

    Annie: Yeah.

    Brian: Can you share with me –? We talked a bit about some of the technical difficulties. Maybe you can take me on a journey. Tell me a bit about what the solution looks like at Broadridge, for integrating first your traditional relational databases into CI/CD. And what are the solutions? What challenge did you run into? How did you implement it? We’d love to understand some more of the details.

    Annie: Okay. We just use two tools to do this. One is for the source control, GitLab. So we just tell the developers to check in their code in GitLab. And when it’s ready for deployment and when it converts to an artifact, then the process can kick in. So a nontechnical person will run this build from Jenkins. So this is the whole point.

    The first and very – difficulty, I would say, is the understanding. The whole Jenkins is integrated with the other tools, like GitLab or Nexus or any other tool. So that was a challenging thing for me.

    We really need to understand how they can talk to each other, with what credentials. So that’s the starting point. So, luckily, our DevOps team has a very good standardized process. So they have created service accounts for each technology, for each build. So those cannot be shared. The password cannot be given to the individuals.

    So the service accounts can talk to the other tools, the other DevOps tools. It could be GitLab or Nexus or whatever. So that’s the first challenge from my side.

    Brian: And do you use credential management in Jenkins for this?

    Annie: Yeah. We have credentials created in Jenkins itself, which is highly encrypted. So Jenkins uses the credential file to talk to the other tools.

    Brian: Talk and execute the automation or orchestrate.

    Annie: Exactly. The same applies for the database credentials as well. In our setup, as I said before, when you click the button, the system downloads the artifact, makes SQL connections. It’s how it’s going to make the connection. So it needs credentials.

    So we instruct the developers to submit a configuration file for us, which just had the connection information, nothing more than that. So what is your target server name, target DB name? Which object do you want to backup or do you want to skip the backup? So it’s like a ten-line config file. They just need to say yes or no or they need to fill the right-hand side.

    So we just give them the template. So they are just going to fill the right-hand side of the config file. So there they give us all the connection information, but the credentials are managed by DBAs. So we create the user name and password in the credentials file to make the connections.

    Brian: Okay. And then they are submitting – to stay in the technical implementation level for a bit, the developers, one, I notice you’re shifting left. They’re empowered to deliver at a speed that they need to deliver versus filling out a ticket, having a phone call, crafting an email. You guys are empowered as the DBA or the database team to focus on higher order, higher level issues. So there’s a lot of benefit there.

    Now, I’m curious. Was it a shift for the developers? Are the developers directly submitting SQL or DDL?

    Annie: No. They’re not allowed to. The Jenkins setup is like we have non-prod and prod server setup. In non-prod, the developers can play around with it, like in a development environment. So they can submit a sample artifact, and they can just try to run the code – sorry – Jenkins job to understand how it works. That’s all they can do. Then when the artifact is ready to be promoted for the higher environments, they can’t touch anything. So there is a different promotion process we have on the DevOps team.

    Brian: Okay. I was curious about that. Right.

    Annie: The DevOps team actually has a process. They call it a promote artifact process. So even they can’t do anything about it. Once they say the code is tested in development, the process kicks in that promotes the artifact to a different source repository. So after that, they have no luxury to go and change the code. So that’s done. So when you test something in development, that is going to production. So that’s the word I use, traceability, right.

    Brian: Right, and it’s similar to retrieving application artifacts and the value of binary repositories, which is build once and promote.

    Annie: That’s it, yeah. I wouldn’t say it’s continuous delivery, but we are targeting that continuous delivery. What I understood is when you push a button for development, when it completes, it goes to QA prod. So that’s what continuous delivery, what I understood so far. So that is not actually in place, because that is actually handled, coordinated within teams, because there is a different change control process.

    Brian: Right. So there’s manual intervention. You’re automating, but your automation has to work with existing change control processes.

    Annie: Exactly, yeah.

    Brian: And in reality, when we’re dealing with data in a financial institution, those change control or change management processes are likely going to stay.

    Annie: Exactly.

    Brian: It’s not practical or not –

    Annie: Yeah. We have a governance team to approve the change for production. So that’s when there is an intervention. But even there is a manual … that’s like a release management flow. So that flows automatically. Then when it’s ready to go, the button can be pushed for prod. So CI in place, CD on the way.

    Brian: Right. CI in place, CD with manual gates is in place.

    Annie: Exactly. That’s the right word.

    Brian: People get on themselves. I speak to many organizations, “Well, we haven’t implementing continuous delivery.” I maintain that at the end of the day that there’s objectives for higher quality, optimization of effort, and increased velocity. If you can do that while still maintaining your manual checks, well, you’ve achieved your goal. It might not be pure continuous delivery. Maybe you guys will get there one day, but –

    Annie: Exactly. I don’t believe in this CI/CD.

    Brian: There’s a place for it at Broadridge today. But that’s where the DevOps comes in. I’m curious. Alignment is always a struggle, right. So this, yes, you still have governance in place. These changing systems, cloud, DevOps and automation must have changed the way you work and have had sort of some cultural implications.

    What did Broadridge do to get teams aligned, to get everybody sort of shifting into this new way of working?

    Annie: Right now in Broadridge, every week have center of practice conferences, where we educate people to understand the existing model. Then we tell them how to onboard themselves into this process. So we educate them.

    We have Confluence pages created for them. So we publish periodically. Then in every COP and COE meeting, which is conducted by the DevOps team, they invite us as a guest, as a speaker, to tell them how any team can get into this process. So every day we get customers. That’s how I would say it.

    So we have multiple application teams. After each and every meeting, we would get five to ten emails saying, “Hey, I want to jump into this process.” Even this morning I got an e-mail. I’m out of the office. I got an e-mail saying, “Hey, I want to jump into the process.” I said, “I’ll give you a demo by next week.” So that’s how it goes.

    So people are interested to come. Even though they know the criticality, but they love the process because it eradicates the manual time and errors completely. So that’s a big thing they look at.

    Brian: Would you say that marketing – so you’re getting people aligned by taking a service approach. I heard you use the words, “We’re getting customers every day.”

    Annie: Yeah, that’s what I feel. I belong to the shared services group from the technology solutions team. So we provide solutions to the teams. That’s our goal, so I see them as a customer.

    Brian: Okay. Like a business that’s customer-facing, it sounds like there’s education and awareness. There’s training and marketing.

    Annie: Yep. That’s what we do every week.

    Brian: Continual training and marketing has let to alignment and adoption. And how important was it that you show success? What I’m also gathering is as part of this, you’re positioning what the benefits are of adopting your service. Right?

    Annie: Mm-hmm.

    Brian: I guess I’d ask how important to the growth has it been that you guys transparently share your successes and possibly even some of your struggles and failures?

    Annie: Normally, after we present the first framework, we get a lot of suggestions from the application teams. So I took this very positively. They actually told me, “Hey, your interface could look like this, man. It could look prettier.” I agreed to it because I was only focusing on the logic of the implementation, not the interface look itself. But when it comes from the development teams, they are already well-versed in programming.

    So they tell me, “You could change this. You could modify this. You could put less parameters.” So I adopted those things. So it’s not just a one-way knowledge-share. It’s like a two-way understanding, yeah.

    Brian: Awesome. I’d say for our listeners as well as you, when I hear you talk about creating a baseline, communicating that and getting the feedback from the developers, it very much aligns with software delivery management messaging you’re going to hear at the keynote at CloudBees today, and this concept of not just automating, but continuously improving, so you can get stuff out there, get feedback, and make it better.

    Annie: Better, yeah.

    Brian: So yeah, look at SDM. I hear a bit of your experience being similar. I.e., it’s not just business to customer. It’s also internal critical systems, where you can bring these to bear.

    So can you tell me, in terms of security and compliance, and you’ve touched a bit upon this in terms of data, but the security and compliance, as you stated, is tantamount, is critical in financial institutions. How do you guys leverage DevOps to help ensure audit and compliance, and help ensure that you’re achieving your security and compliance goals at Broadridge?

    Annie: Basically, first and foremost, I would say the source control artifact. That is the first level in auditing and security. So if you want to go back and see, you have a service ticket with a version control artifact. So you know what was installed, on which date, on which server. That is so helpful for auditing purposes.

    Brian: Okay.

    Annie: So for the security purpose as well, since the credentials are managed locally in Jenkins as an encrypted file, it is very secure and it’s not –

    Brian: Centralized secure –

    Annie: A centralized place, so that it’s not being shared with multiple teams or multiple people. Normally, DBAs hold the credentials, but now, no one is holding any credentials. So once it’s created, it’s stored. That’s it. It works very well.

    Brian: Awesome. Thank you. Now I’m curious. I’m going to ask a couple of sort of fun questions, but questions we also like to help inform our audience about who our guests are. So one of those is who is your favorite DevOps superhero and why?

    Annie: I would pick someone from my company. I’m sorry. I’m being selfish. Daniel Ritchie I would say.

    Brian: Daniel Ritchie.

    Annie: Yeah. He’s the man who introduced DevOps to me. Because when I had an interest, I approached him. Everyone in my company said Daniel is the go-to guy. So I approached him. He spent quite a few hours with me, explained about the DevOps CI/CD process. That actually impressed me to do this framework. So I would say he’s my hero.

    Brian: So let’s dig into – Daniel or Danny?

    Annie: Daniel Ritchie.

    Brian: Daniel Ritchie. Thank you, Daniel, and hello, Daniel. So what’s Daniel’s role at Broadridge?

    Annie: He’s a DevOps architect at Broadridge, and he has been wonders for the past five or six years.

    Brian: Awesome. I also noticed this loop here of there’s curiosity. There’s someone that has some experience and expertise. They service the curiosity with that. So it’s sharing and training. People marketed Daniel to you, to be able to go find him. Then now, you’re doing the same, to spread the word within your company.

    Annie: Yeah, true.

    Brian: So yeah, it’s awesome and I love how it underscores that at the end of the day, while there may be top-down components to DevOps improvements, at the end of the day, DevOps is really about sharing, collaboration, and community. I think what you’ve shared with us has demonstrated that.

    Annie: Thank you.

    Brian: So to shift, I like to ask guests to share what we call a dev-oops moment. And that’s not D-E-V-O-P-S, but rather D-E-V-O-O-O-P-S. That’s a moment where either dangerously, precariously or humorously something went wrong and you learned from it. Do you have a dev-oops moment that you can share with us?

    Annie: Yeah. When I was initially developing the framework, I didn’t know how to mask the password in Python script, because I’m not a developer. So when I ran the build, I saw the password displayed on the console output. It was like, “Oops.” I was like –

    Brian: And now you’re like, “How do I get rid of it? Where are the logs?”

    Annie: Then I went back to the CloudBees, how to wrap the password. Then I found the syntax, came back and had –

    [Crosstalk]

    Brian: Shhh. Nobody tell anybody.

    Annie: Yeah. So that was an embarrassing moment for me, but that was just with me, so I just canceled the build.

    Brian: That’s good to know. I’ll tell you. I have had something similar happen. I don’t think it was in a critical environment, but I didn’t catch it right away. So that meant that I’m SSH into servers, combing through logs, trying to figure out everywhere where this unmasked password would have leaked.

    So thank you for sharing that. That’s why those DevOps moments are important. And in that, you said you were able to go to CloudBees and they explained it.

    Annie: Yeah.

    Brian: Do you happen to recall how you masked it?

    Annie: I saw some blocks, block spots, and those guys were really good. So I just posted a question and I got an answer instantly. Yeah, within like a few minutes I got an answer, with syntax, so I could wrap like this. They gave some examples.

    Brian: Then on interpretation and complexity it’ll obfuscate it.

    Annie: I just used it for my thing and then I went back and learned.

    Brian: Also a lesson about testing locally first, right, before it went into the pipeline.

    Annie: Exactly.

    Brian: Awesome. Do you have any final thoughts that you’d like to share with us, in addition to the experience and knowledge you’ve already provided, any final words for the listeners?

    Annie: No. I’m so glad that I’m here to share my experience about the framework we have. I’m so happy to be here.

    Brian: Awesome. I’m going to poke and prod you a little more. Now that you’re at DevOps World/Jenkins World, was this your first one or have you –?

    Annie: Yeah, very first one.

    Brian: Okay. What are you looking forward to getting out of it?

    Annie: I would like to know about the things which I do not know so far, because my level of DevOps is very limited. So I would like to know how I can improvise my framework with the available sources. So I looked into the topics and they were so interesting.

    Brian:Awesome, great. I’m pretty convinced that in terms of better understanding CI/CD, DevOps and what you can do in particular to do it, to apply it within and enterprise, you will learn more here. I’d love to hear from you, if I see you again later in the show. I’d love to hear from you how your experience has been and what you’ve learned.

    Annie: Thank you so much.

    Brian: All right. Thank you, Annie.

  • Jenkins X Continues To Experience Strong Demand, Speeding Development Of Cloud Native Applications

    CloudBees introduces first GUI for Jenkins X as downloads, contributors and corporate support to the open source project grow

     

    KUBECON SAN DIEGO, CA. AND SAN JOSE, CA. – November 20, 2019 – CloudBees, the enterprise DevOps leader powering the continuous economy, today introduced a graphical user interface (GUI) for Jenkins X at KubeCon San Diego. CloudBees’ announcement comes at a time when the Jenkins X open source project and CloudBees’ support for the project are both gaining momentum at a rapid rate, with contributors and supporting companies hitting all-time highs.

     

    In less than two years, approximately 885 developers have contributed code to the Jenkins X project and there are 176 contributing companies (Source: Continuous Delivery Foundation DevStats, October 2019).

    Jenkins X offers automated CI/CD for cloud native applications on Kubernetes. Using Jenkins X, developers can leverage Kubernetes to build and deploy cloud native applications quickly and easily without having to learn the intricacies of Kubernetes and its ecosystem. The Jenkins X project, initiated by CloudBees and other contributors in February 2018, is now part of the Continuous Delivery Foundation.

    “As a software developer in charge of migrating monoliths to microservices deployed to Kubernetes, Jenkins X has helped me and my teams to be efficient in managing complex projects that require 100+ source code repositories to be deployed to different Kubernetes clusters,” said Mauricio Salatino, principal software developer for a workflow and decision automation platform company and an instructor at Learnk8s. “This was a task that initially looked impossible for a team of just four people, but we did it easily with Jenkins X.”

    Jenkins X continues to be enhanced at a rapid pace. CloudBees’ introduction of a new GUI in its CloudBees Jenkins X Distribution gives developers more flexibility and a richer user experience. The existing command line interface (CLI) loved by many developers is still available and continues to be enhanced, but now users have a choice to use the CLI or the new graphical environment, depending on which better suits their workflow. The CloudBees Jenkins X Distribution is a free offering from CloudBees.

    “Our goal is to make Jenkins X the most friction-free environment for developers looking to use Kubernetes in an opinionated, automated way,” said Mo Plassnig, vice president of cloud, CloudBees. “Offering a richer, more intuitive GUI is just the start. Contributors throughout CloudBees and the Continuous Delivery Foundation ecosystem are hard at work creating more improvements – everything from log handling to environment promotions to onboarding of workflows.”

    “The numbers show that our vision for Jenkins X was right on target,” said James Strachan, a distinguished engineer at CloudBees and one of the founders of Jenkins X. “As more organizations embrace DevOps, the need for a CI/CD solution that leverages the power of Kubernetes with the rich capabilities and straight-forward convenience of Jenkins X has continued to grow.”

    Additional Resources

    Download Jenkins X

     

    About CloudBees
    CloudBees is powering the continuous economy by offering the world’s first end-to-end continuous software delivery management system (SDM). For millions of developers and product teams driving innovation for businesses large or small, SDM builds on continuous integration (CI) and continuous delivery (CD) to enable all functions and teams within and around the software delivery organization to best work together to amplify value creation.

    CloudBees is the CI, CD and application release orchestration (ARO) powerhouse, built on the commercial success of its products as well as its open source leadership. CloudBees is the largest contributor to Jenkins and Jenkins X, and a founding member of the Continuous Delivery Foundation (CDF). From startups with full-stack developers practicing NoOps to large Fortune 100 companies, CloudBees enables all software-driven organizations to intelligently deploy the right capabilities at the right time.

    Over 3,500 of the world’s best-known brands and over 50% of the Fortune 500, invest in CloudBees because of its ability to work across any cloud, in any development environment and to balance corporate governance and control with developer flexibility and freedom. CloudBees is home to the world’s leading DevOps experts, helping thousands of companies harness the power of “continuous everything” and putting them on the fastest path from great idea, to great software, to great business value.

    Backed by Matrix Partners, Lightspeed Venture Partners, Verizon Ventures, Delta-v Capital, Golub Capital and Unusual Ventures, CloudBees was founded in 2010 by former JBoss CTO Sacha Labourey and an elite team of continuous integration, continuous delivery and DevOps professionals. Follow CloudBees on Twitter, Facebook and LinkedIn.