Hot answers tagged

47

A big part of DevOps is making it possible to release very often. That comes with automated build, automated testing, etc. You can say that to achieve its goals, DevOps need to use automation to be efficient. Here's how DevOps and automation are related. DevOps is not just automation, there's more to it. Conversely, automation is not exclusively used by "...


41

A "Walking Skeleton" is a form of "proof of concept" of your basic architectural concept. Where a proof of concept typically focuses more on a single functionality, a "Walking Skeleton" is a minimalistic end-to-end implementation. A "Walking Skeleton" is not an outline of your concept (only a "skeleton") but is really executable and shippable (it can "walk" :...


34

My first thought is "why is the he the only person doing ops, on a dev team, especially when he gets to work with loads of automation?". I think there's an opportunity there to address the lone wolf syndrome; particularly in a dev environment, infrastructure-as-code provides a great framework for sharing the load. Ops people should be experts in ...


26

I think the first flaw is in this sentence: He reports to the Development Manager, but works more closely with the Infrastructure Manager. DevOps is a cultural shift aiming at removing silos. If silos remain, then this engineer is whatever you want to name call him; an engineer doing operational development, an automation expert, a developer automating ...


24

TL;DR: You should never try to hire a DevOps Team There are essentially three most common roles to hire for: DevOps Architect / Evangelist DevOps Engineer CI/CD Engineer These roles are distinct from your 6 essential software development roles that traditionally compose the software engineering organization: Product Management Software Development Tools ...


19

I think the easiest way is to change their performance goals so they are based off reliability as well as delivering code. Sell it as the company cannot succeed without both so why should the developers only be measured on one? The best way for them then to meet their performance goals is to be involved in operations. Ultimately you need to convince them ...


18

Feature toggles are a common practice in high-velocity development because they de-couple development from release. Dev teams can "soft-release" a new feature to production, in a disabled state. This allows the feature to be released any time. If the feature is dependent on other work or preparation, it doesn't have to wait for a major release to go to ...


17

The most important thing for DevOps Engineers in this kind of situations, is to get (a) Management Commitment and (b) Required Budgets. Read on for some more details on both ... Get Management Commitment Once that is in place, things become easy for such DevOps engineers. Especially whenever resistance (from all sorts of parties) comes into the game. Trust ...


16

I'd agree this is a buzzword as much as DevOps can be. Main task of a SecOps added on top of an usual operational engineer tasks is to take the burden of following CVE publication feeds, handling the remediation, usually handling things historically handled by the security or network administration team (Firewall rules, Web Applications Firewall exceptions) ...


15

Automation is a key attribute of DevOps, but it's not the full story. The question is kind-of like "What's the difference between time-boxing and Scrum?". You'll hear DevOps called a 'culture', a 'movement', a 'methodology', and all kinds of things that won't box it in well enough for you to understand it, even though those descriptions are accurate. In a ...


15

In most cases, the recommended books are not about technology. While technology changes, the fundamental principles behind organizations like system thinking, leadership, common sense, etc... do not change as often. Books such as The Goal, and even The DevOps Handbook do not mention much technology on their pages but rather ways to manage work being ...


14

I need to put my answer to this question in the context of what DevOps is, more specifically within the DevOps transformations I have been part of, DevOps is the ownership of the full Software Development Lifecycle. All of the practices in the chart are an important part of DevOps, and they enable and underpin both Systems Thinking and Amplification of ...


14

Being a consultant I am contractually obliged to answer, "it depends". With that out of the way, I can actually answer your question. What does it depend on? Well, that could come down to what your boss thinks about DevOps: If your boss has heard of the term, via their obsession with CIO.com maybe, then ask them what they think it means. From there work ...


13

DevOps is really a cultural shift - it's intended to be about breaking down the traditional barriers between operations and development (and really also with QA and the rest of the business!). The idea is that rather than having departmental 'silos' you can work directly with other teams to get things done quicker and more efficiently. It's all about ...


13

It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies, this shift can be shortly described by the “You build it, you run it!” coined by Werner Vogels: There is no need to distinguish between building and running, and according to Werner Vogels, it is much better than that: ...


12

I don't think there are any "universal" DevOps KPIs. For example, velocity is great, unless it's not a key driver for your business. Amazon cares a lot about velocity because they have a massive retail operation. That's less important for a small app with 100 users. This begs the question: how do you select the best KPIs relevant to your business? That'...


12

There are two types of work: Exploitation - Well defined work that can be easily divided into well-defined stages, where each stage can be learned and mastered on its own and handover between stages does not require communication. Exploration - Undefined work, which requires learning and experimentation to accomplish each stage and handover between stages ...


11

IMO DevOps is culture, much like Agile (without choosing an agile methodology.) Therefore you don't "do" DevOps. You "do" a release methodology called Continuous Delivery as part of a DevOps Culture. (full disclosure, I don't think I've ever referred to CD as a release methodology before, but in my jetlagged state I think it works) If you'll buy that, then ...


11

When it comes to affecting business culture, the best way is probably via the well-known "boil the frog" method. You have to introduce these tasks to developers slowly, because I know I myself (as a dev) would balk at having all this new responsibility at once. First, start out by introducing one or two new tasks only to be performed during normal business ...


11

TL;DR: Infrastructure as Code is a way to automate and backup your environment. In ideal case, after a disaster, you could restore your Infrastructure fully and automatically by Provisioning new resources, Restoring Configuration from Code Repository and Recovering Data from Backup. Overview Infrastructure as Code relies on three main concepts: Automation ...


11

DevOps in a nutshell From Wikipedia: DevOps (a clipped compound of "software DEVelopment" and "information technology OPerationS") is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and ...


11

It is always ethically acceptable to fork any code on Github (or Sourceforge or wherever you got it from) and do whatever you want with it, within the terms allowed by its license! This is what open source and permissive licenses are all about. The original author wanted the world to contribute to this piece of software, and you will be doing exactly that. ...


10

DevOps tends to break down across three major dimensions: Culture DevOps culture emphasizes high levels of trust, collaboration and communication between all stakeholders, especially Dev, Ops, and Security. The natural tension and competition between these groups creates friction, and often dysfunction. DevOps is (arguably) first and foremost about ...


10

I have been practising and advising on DevOps as a consultant with different clients for almost five years now, before my current position, I held roles in software development, web operations and systems administration. In my personal experience DevOps comes in many flavours. Organization Patterns DevOps Antipatterns: NoOps and NoDevs - not strictly ...


10

I'd argue Devops Engineer as described in your question link is mainly a sysadmin role. Quoting the skills here for background to this answer: Your climbing gear. Strong background in Linux/Unix Administration experience with automation/configuration management using either Puppet, Chef or an equivalent Ability to use a wide variety of open ...


10

DevOps isn't just a different way of doing things, it is a better way of doing things. Perhaps it will help me to make my point if I rephrase the question in a different context - the context of the industrial age, the railroad and the steam hammer: Does a railroad company need Steam Hammers if it already lays track at an acceptable speed? I mean, ...


9

It is a fascinating question for which real answers may not actually exist; I appreciate that while you tried to keep the question contextualized on the VCS, it naturally scaled by itself up to infrastructure design and implementation planning. Though, it seems many of us are working of this kind of transitioning, which can be exciting, but at the same time ...


9

Looking outside of DevOps specifically, if you are talking about large (ish) enterprise environments then the SAFe methodology has a fairly good way of encouraging this kind of behavior. Essentially it boils down to a few key stages: projects start as release trains. The intent (and the expectation of whoever is funding it) is that it will be long running. ...


9

IMHO that depends on what the role of the tester was before such transformation. BTW, I believe my answer applies to the DevOps transformation in general, not only to the You build it, you run it paradigm. If the role was a drone job - mindlessly executing tests - it's bound to go away, automation will eat such jobs. If the role included writing the test ...


9

This is not docker-specific, but this general rule for evangelism applies: different audiences require different evidence. In general, software developers (and managers from a development background) want to see it in action, so POC's with measurable outcomes are preferred. Other disciplines and executive stakeholders may be OK with case studies and ...


Only top voted, non community-wiki answers of a minimum length are eligible