Tag: CAMS

  • Never Mind the Bollocks, Here’s the DevOps

    Never Mind the Bollocks, Here’s the DevOps

    What is DevOps?

    “DevOps is a cultural and professional movement” –Adam Jacob

    [movement (n): a group of people working together to advance their ideas.]

    So, who are these people and what’s the big idea?

    The people are system administrators, developers, product managers, QA technicians, security analysts, network engineers, and anyone else involved in the business of developing software.

    The big idea is to increase the value your product or service delivers, more quickly with less effort.

    (Having a product or service that is designed and built well isn’t inherently valuable. The value comes when your customer is able to use your product or service to solve a problem. DevOps is all about delivering value quickly and effortlessly.)

    DevOps practices and technologies are evolving, but here are some of the core concepts paraphrased–be sure to read the links in the footnotes for the full explanations:

    The Three Ways

    • Systems Thinking
      • Learning how everything is interconnected, from concept to customer
    • Amplifying Feedback Loops
      • Cutting the time between action and reaction, failure and success
    • Culture of Continuous Experimentation and Learning
      • Recognizing failure is important data about how and where to improve

    CAMS

    • Culture
      • It’s about how people relate and work, not something you can buy
    • Automation
      • Faster, less error-prone processes help amplify feedback loops
    • Measurement
      • You can’t get where you want to be until you know where you are
    • Sharing
      • Effective teamwork ignores organizational boundaries

    ICE

    • Inclusivity
      • Everyone is responsible for (and benefits from) these practices
    • Complex Systems
      • Because simple systems are simple
    • Empathy
      • Real collaboration requires real understanding of another’s point of view

    That’s the theory from a very high level; the following Q&A provides some broad explanations of related concepts. These are actual questions I was asked in a recent discussion of DevOps.

    Q: What specific skills or experience do I need before I can put “DevOps” on my resume?

    A: It depends. At this point in time when recruiters and/or hiring managers list DevOps in a job posting they are almost always looking for a “DevOps Engineer” (i.e. a sysadmin who knows just enough coding to be dangerous), or a “full-stack developer” (i.e. a developer who knows just enough about system management to be dangerous). The reality is that (as of today) there is no DevOps certification, organization or even manifesto, so anyone who pretends to authority on what is and isn’t DevOps is overstating their case at best, a charlatan at worst.  

    Q: What is source control?

    A: Source control is a repository for files that make up a modern software application during development. It maintains a historical record of changes so it’s easy to review (or rollback to) changes made to an application’s source files. The most popular source control technology today is Git, and GitHub is one of many online services used to manage Git repositories.

    Q: What is Jenkins?

    A: Jenkins is to task engines or “build servers” what Kleenex™ is to facial tissue. It’s currently the most widely used software product for automating various functions of software build and deployment. For example, a system might be configured such that any code change pushed to source control triggers a job in Jenkins to build, test and deploy that code.

    Q: What is configuration management (e.g. Salt, Ansible, Puppet, Chef)?

    A: Configuration management is a means of scripting server configurations so it’s easier to track, deploy or make configuration changes to large groups of systems.

    Q: What are containers?

    A: In the same way that server virtualization allows you to have many isolated “virtual machines” on a single physical machine, container technology allows you to have many isolated application environments on a single operating system. Containers have been around in Unix/Linux for a long time, they just boomed in popularity when Docker came along and made them easy to use. The next version of Microsoft Windows Server (2016) will introduce Windows containers.

    Q: What are microservices?

    A: Microservices are small, independent components of a software application that are built, tested and operated in isolation from the core product. Using microservices enables development to be faster and more nimble than possible when working with a large, monolithic application.

    Q: What is Continuous Integration/Delivery/Deployment?

    A: Continuous Integration is the practice of continuously integrating (and testing) new code with your existing source code. Continuous Delivery is the practice of automating as much of the build/test/release process as possible while still requiring a manual push to production. Continuous Deployment is the practice of fully automating build/test/release all the way into production.

    Q: Are there any conferences or meetups I can attend to learn more?

    A: Yes! The original DevOps conference is DevOpsDays and there are many of these events around the world annually. A popular conference with large enterprises is the DevOps Enterpise Summit.  Various DevOps-related meetups (#CoffeeOps on Twitter) are springing up around the country. Check the CoffeeOps.org website for details, or search for DevOps at Meetup.com.

    Q: [Do I need to understand everything above | Is this all I need] to be or do DevOps?

    A: Absolutely not, on both counts. You can successfully implement a DevOps way of thinking/working by incorporating all or just some of the above, and there are many other tools and practices around delivering value more efficiently. Naturally there are extensive resources available (a few linked in the footnotes) to do a much deeper dive on all these subjects.  

  • How DevOps could save the world; like your colleagues’ day

    How DevOps could save the world; like your colleagues’ day

    DevOps is about a few things but above all, it’s about communication and understanding each other. In that spirit, I decided to create a new day to celebrate: “Like your colleagues’ day”. The rules are simple:

    The first rule of like your colleagues’ day is: You do not talk about Fight…

    • Each year, on the last Thursday before summer (Thursday the 18th of June this year).

    Thursdays are ideal days to make people happy since they’re right before the week-end but not totally there. Right before the summer as it’s all sunny and nice outside.

    • Present a token of your affection to your dear colleagues. Remember, it is a token, not a romantic dinner for 2 in a 3 stars restaurant in Paris. It could be anything from a rose to a beer after work or anything that makes sense to you and the person who receives the gift.
    • Since DevOps is all about loving each other, the day is called “colleagueS’ day”, meaning that you should make as many people happy as you can. A box of chocolates for a team is a good way to make many happy at once for example.
    • Once again, DevOps is about love so you should also consider this day as a good opportunity to bury the hatchet. If you have notoriously grumpy colleagues, maybe all they need is some consideration. A smile, an uninterested chat (meaning you actually listen to what’s being said and do not expect anything in return) and maybe a sweet or a coffee are excellent ways to make people around you happy.
    • Even better, try to make someone you do not know happy. After all, people you have not talked to yet might be full of surprises, right?
    • Money is not the point. For once, you can bake a cake, you can offer to get coffee for your colleagues, you can listen to them and maybe even share a bit too, after all discussions are better with two or more persons.

    Actions have consequences.

    It’s quite simple really, once you’ve introduced your colleagues to the concept (beforehand for better results) and the day has happened, take a step back and draw your own conclusions.

    The first few times I have tried this, only a few persons followed but as the actions were not focused on one person only, others got to enjoy the day and joined in in later editions. The results were above expectations, people got to talk about food, cakes and pretty much everything that can be said during mingling. Where I really saw a good DevOps potential in this is when people from different teams started to play the game and started to communicate together. Some went for beers after work and got to know each other, making things smoother and easier at work afterwards.

    LYCID is also a good opportunity to have activities. While you can think of a management breakfast, it’s not too hard to imagine a technological lunch where everyone is invited or a wine/beer lottery in which everyone can play. As long as the normal work time is respected, everyone should be happy.

    Don’t stop me now, I’m having such a good time.

    Well, you get the point by now, make your colleagues happy and try to create a better work atmosphere by being nice to each other. But that should also open your mind a bit and maybe you could apply a layer of niceness to the world around you. Let people out before going in the subway, hold the door to the person behind you, try to smile when you think the moment is right (you have to figure that out for yourself) and why not, give your change to the first person in need you see.

    This can sound naïve, maybe borderline stupid but imagine a world in which people were nice to each other, no matter the social class, gender, religion… If we were a bit more tolerant, a touch nicer to everyone and a tad less self-centered, this world could actually be really pleasant to leave in.

    Add a pinch of DevOps in that and what do you get?

    Repeat the operation as many times as you want, being nice never killed anyone. Make it a part of your personal and professional culture to be nice, available and polite. Through an iterative process, determine when you can smile without looking like Forest Gump and after a while it will be automatic, you will naturally become good and this will feel nice, trust me. Check the impact of what you did on your colleagues, measure their happiness and if you think things did not change enough, don’t wait until next year, be spontaneous and repeat the operation. After all, baking a cake and getting the coffee for your team should not take too much time or efforts, should it?

    If you feel this could do a difference, spread the word, DevOps is about communication and sharing. Feel free to improve the rules, feel free to ignore some, in the end, all I want is to make you happy.

    I’ve said this before during a conference but as we talk about unicorns, rainbows and other nice things when we mention DevOps, why not dream that we could also make a little difference in the world surrounding us. A little is better than nothing. DevOps could save the world!

  • DevOps across the Enterprise: Fostering Cross-Functional Collaboration

    DevOps across the Enterprise: Fostering Cross-Functional Collaboration

    DevOps practices originated at startups, where nimble Development and Operations teams pioneered the concept of cross-functional collaboration to speed up software release cycles. By 2009, DevOps became a recognized industry practice: a software development methodology that promised higher velocity for enterprises working to get products to market more quickly. Many enterprises have since embraced DevOps among their software development teams, and early adopters are now taking it beyond code to other parts of their organization.

    Unfortunately, successful cross-organization collaboration is uncommon outside of Dev and Ops teams. With the Internet of Things bringing software and hardware together in previously disconnected devices and industries, collaboration among design, development and product management teams has become crucial. There are technical, procedural and cultural challenges which must be addressed to bring the same level of DevOps success to other areas of an organization.

    The State of Collaboration

    An important place to start is understanding the interactions between different groups in an organization.

    Consider one of the most frustrating areas of the software release process prior to DevOps-style collaboration. Builds would be “tossed over the wall” from Development to Quality Assurance, and then from Quality Assurance to Operations, with each team moving on to other things as soon as a build was handed over. Visibility into the overall status of the project was non-existent.

    When other departments collaborate, what is the level of visibility into the work being produced by the groups that depend on one another? Does marketing know if the latest feature made it past the initial legal review and the likelihood of it being included in the final product? The answer is usually no; there is little visibility into the process and decisions are shared close to project deadlines. Applying DevOps practices to an organization’s entire product pipeline changes the collaboration paradigm, expediting time to market and improving overall quality.

    Culture, Automation, Measurement and Sharing (CAMS)

    CAMS is relevant when both technical and non-technical teams collaborate. As seemingly unrelated teams are required to work together, it’s important that they have a culture of shared accountability.

    Skipping the details of specific tools and technologies, one key consideration for organizations to recognize is that automation is crucial to a repeatable process, enabling speed and scale. It also provides a high level of visibility, as it’s closely coupled with the sharing of data. When only one team is manually updating metrics, communicating what’s going on is manageable. But what happens when other groups are dependent on work being produced by a group that’s updating its data manually? What if multiple groups depend on knowing the status of a task in a timely manner? Manual processes result in an endless flood of phone calls, emails or instant messages asking if information is up to date.

    The measurement aspect of DevOps opens up a can of worms. It’s important not only to determine what should be measured but also to have a common way of discussing how it’s being measured. Establishing a common vocabulary across an organization for day-to-day tasks can be extremely difficult.

    In these situations, it is important to go back to the core benefits of trying to bring the DevOps style of collaboration to other groups in an organization.

    1. What is the desired business outcome?
    2. Why don’t current processes meet requirements?
    3. How could change positively benefit employees’ daily work?

    As people become comfortable with “why,” discussions of “how” become easier.

    Once changes are underway, it’s important to make sure that there is a single place where people can obtain accurate status updates and share information. Bringing DevOps into the enterprise takes time, but providing visibility into any project in an automated, transparent manner will show the positive impact of sharing information in a timely way.

    Most importantly, try to quickly demonstrate success—however small. There will be roadblocks, political objections (an unfortunate reality) and people who just don’t want to change. But by measuring and demonstrating success and tying it back to business outcomes, you will set up your organization for success.

    Like many other initiatives, the key to a successful DevOps program is intention. To drive this home, an old joke: how many therapists does it take to change a lightbulb? Just one. But it has to really want to change.

    About the Author/Jonathan Thorpe

    jonathan_thorpe_origJonathan Thorpe, Technical Marketing Manager, Perforce Software –Before joining Perforce as a Technical Marketing Manager focused on Continuous Delivery and DevOps, Jonathan Thorpe held technical marketing roles at CFEngine, Serena, and Electric Cloud, where he specialized in DevOps culture and automation technologies. In his spare time you can find him reading, playing with all of the current video game consoles, dabbling with mobile software development, and playing with the Raspberry Pi.