Bestand wählen
Merken

Practical Management of the new Shape of Applications With Chef Automate

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
this is the road more traveled a look at putting Dev transformation back on the rails my name is George Miranda IMO director of product marketing at shaft I've been a check for about 5 years now and when I 1st started shaft is doing a lot of consulting and field work which means that I'm gonna work with us a more largest and most successful customers various phases of the Dev Ops transformations transformation that's been very interesting for me to see where they were when I 1st met them forces where they are today so if you find out with me in the field and you me you probably know that I'm a big fan of being an agent for change and mean if we haven't met each other well say is that change is a constant theme in my life that extends well beyond just the scope of technology of for example just in my time at Shepherd live in 3 different cities alone let alone all my time on the road i'd like to bounce around from place to place look at a lot of different settings I grew up in Los Angeles anybody here from socal 1 person I call you're you're by people you probably know where this story's going next but for everybody else I'm also this month and just a very very dynamic city and the downtown area of Los Angeles has just undergone its own radical transformation when I was living in Los Angeles downtown Los Angeles was known for this it was known as skid row by hand not the sort of place you want to be after dark mean sure there was a bustling daytime commerce become by nuclear then there is nothing that you there's a very tumultuous things going on in city at the time and city leaders realized that the only way for loss and list to evolve and move forward was to radically change how the city was structures the request the question became how do you drive change on this sort of scale the the and L is a really massive enterprise Ray um the scale of the universe is about 13 million residents with an estimated 750 billion dollars of revenue by three-quarters of a trillion dollars that's a massive enterprise but if you look at the state of downtown Los Angeles today it's almost unrecognizable it's completely transformed downtown LA is now known for being gallery row and it's a booming economy it attracts a set of diverse professionals from all over the globe to live there the beacon of creativity in the city Center for art the nightlife and there's a real estate boom going on in downtown often does that is unlike anything that they've seen in the 1920 so more growth in they're almost seen in over a century failing how do they pull up their transformative magic and had only give me some that the for it's mind-boggling in terms of complexity and scope because when you drive transformation you have to that how you fundamentally transform every moving part of it when it comes to a city like Los Angeles right and mean the your coordinating the needs of a diverse set of groups with diverse gold they whether they're real estate developers are investors freight transportation of merchants a big business employers right public safety environmental impact like the list goes on and on and on so how do you get a transformation at the scale of loss and this right how you enable a push that throughout the entire organization where you do you set up a very small focused task force that has maybe 2 visionaries on it and like super Shop project manager with an amazing can on board filter all change through them and certainly will drive this transformation city at no right I get the from smiles at that sound ridiculous right it sounds even ludicrous to say out loud if I talk about transforming a Fortune 500 IT organization like and so you see some nodding heads right like that sounds about right because that's all we see many times so why is the former absolutely ridiculous amount black what lessons can we learn but about transformation happening on that scale right what can we learn about replicating these types of successes inside our own organization if I found was getting ready for this talk and in my search I discovered that there now cities around the world trying to replicate the same success as downtown Los Angeles and whether that's domestic cities like Atlanta Savannah Nashville or international cities Bogota Delhi at Copenhagen isn't really interesting things I the cities are not trying to figure out how the drive wide transformation is really eye-opening them you see what some of apparel work so cities that have successfully done this realize that they cannot be a central polymer chain instead the need to decentralize expertise and make it clear what the parties are so cities that successfully transform to it by setting up self-reinforcing cycles that start with identifying the right metrics the way you drive transformation through 3 quarters of a trillion dollar economy is a start by focusing on things like this so this slide is pretty interesting because the metrics at the top the the outcomes at the bottom that a surprisingly 1st look at the many metrics like what the hell do one-way street versus two-way street have to do with vitality vibrancy in resilience right we start unpacking the seawall one-way streets a really great for funneling traffic through downtown area but they're really terrible for generating foot traffic and if you don't have strong foot traffic and you're not going to have strong retail in that neighborhood need strong retail to drive neighborhood revenues have strongly red revenues you can track higher rent the have higher rent prices of developer the want to build more housing units to bring in more residents and feed the entire cycle and keep go may also that foot traffic creates a sense of neighborhood and community the and that's really necessary when you fall on hard economic times neighborhoods inevitably do you need to have some resiliency to make it through and then you support that those behaviors with infrastructure in this case the way that people get around i by changing the way that people get around you create daily behaviors that force there were reinforced the cycle and make those daily behaviors and habits so that 1 seemingly arbitrary metric has a world of innovation attached to it when we start to unpack what it means to actually deliver on that number so the way to succeed in Dev Ops transformation is to set up a self-reinforcing cycles in your own organization you do that 2 ways 1 you start by identifying the right metrics that matter and do you put in told that reinforced the behaviors that you want to see on a yearly basis setting up those self-reinforcing cycles the only way to steal communication drive culture change across a diverse set of team with a diverse set of gold organ about but that they in the talk about metrics tools and the science of change Oh and going to do it with 1 more thing
right so the title of this talk on the road more travel but a Robert Frost reference right on the road less traveled underway video the poetry fans are English majors literary deep in the room like couple folks are a anybody know what's wrong with what I just said the evidence that the title the title of the talk years or so the title poem is incorrect but it's not the road less traveled with a road more traveled actually the road not taken and I think the only thing that's mistaken more often in the name of the poem is the sentiment behind right everybody knows upon that I mean 2 roads diverged in the woods and I the 1 less traveled by right so that Paul when you read it the 2 roads are essentially the same like there's no discernible difference in actually doesn't matter which 1 the offer and so the call the poem exactly commentary about the stories that we tell ourselves to justify the decision that we make and so I see that happen a lot in transformation initiatives which is you hear stories about some decision that work in 1 organization that don't work in others there's a lot of anecdotes the media tend to be your strongly so instead we're going to take the road more trap right which means we're going to look at empirical data we look objective observations and we're going to identify what actually works and proven path to success so I could deal cool
identifying the right metrics and I got this next part from Dr. Nicole Foss brand if you want to start capable of I the call sort shaft to now words as derived about research and assessment and you can make euro when it comes to the science of metrics and how that sheets behaviors are if you really wanna get into it and died debating she as a way better job than I ever record about how you science the crap and about the shares some really wonderful talk then I suggest looking up if you want the but this next part is a really good summary and any comes from Eli Goldratt author of the goal it and he writes this tell me how you measure me and I will tell you how I will be the breakdown is basically this right you should always measure the things that matter because that's how you communicate right if you don't measure it probably doesn't matter right if you don't measure don't expect anyone to do anything about it and in business this usually played out because the incentives are tied to certain measurable goal when the most obvious example is the sale right you close a deal this certain way and you get paid and so the and business especially we tend to orient around behaving in ways that achieve on sense so measures are important because they drive our behaviors but right individual measures have a way of maybe leading to unintended consequences if you just look at them in isolation and so the example of that is that's right if you define a metric that that were in a ship X new features to users every week but you can expect that the behavior they're going to get from that is that your developers going to sprint to get x number of features and so the release every Friday and that necessarily the right thing to do you may be right maybe x is the right number maybe it isn't but it has an unintended consequences and that this might be letting or setting you up for a support right maybe those features on fully ready to go but the thing that matters is getting X number out there right so maybe deliver things on fully Bates or maybe you spend to get those in at 5 pm before everybody goes home and then your often supporting the clean that up over the weekend when but hey like I got those features out like high broke a job right metric achieved and so what happens is we inadvertently set of situations where people strive to deliver on those 1 metrics that we that that we defined right of human we define consequences decay the consequences are damned out of malice right consequences again because we're measuring right we can communicate that they're actually important in teams will optimize for the given constraints right so unintended consequences slip through the cracks because we did decide to measure them attract them and because of that some organizations take the exact opposite approach tribal go ahead and measure everything right and so if you if you do that and go that are we have a way of creating a lot of noise from which it's very difficult to extract the signal so the key is really to you identify a small set of metrics that when taken together start creating a self reinforcing web of behaviors that shield you from unintended consequences and what I found that was astonishing when I started looking at how cities transform is that a number of city there now going down the transformational perhaps managed to drive large-scale change with only about a dozen or so leading indicators and metrics the prime behavior and so via the state of the art report has been around for of about 5 years now right of 2013 Increase of set 2017 from for 5 years and from the data we've learned a lot about how IT industry performance plays out and we've learned that there's certain measures around speed efficiency and risk their correlated with how high performing teams and leave the were lead the industry and and leave the rest of their peers behind a chapel we've done is we've adopted here this data along with the data that we've collected from our own users to derive a set of metrics that starts to create back cohesive web of practices the and it looks like this right so we organized the data in a pretty easy Apollo prescriptive path and the categories are measures of speed efficiency and rest NEC metrics that define what high medium and low performing organizations now you might recognize some of this from 2016 state of the art report and you might recognize the rest as a sum of the data around findings that work in that report the chapters used in tandem with data that we know about our own users to drive some quantifiable measures for those findings so a couple things note here another way it all comes together so the lines between high medium and low performing organizations was art arbitrary side the me sat down and said hey this is what it means to be a high performance of form this is an a prescription of the data it's an interpretation of what was there when he looked at performance data points across the IT industry the disorder naturally organize into these clumps very large performance gaps between right so that we're seeing a reflection of in the truck on 2 uh the compliance automation data on that we've gone from the chef community follow those same distinctions and that should make that kind of sensory reason because 3 and this a cohesive Weber practices when start to deliver on 1 of these metrics has a way of unpacking the others in bringing those practices with and so going back to the city example right it's not that the number of open-air markets per square mile is what transforms your city it's that measuring the number of an open-air markets per square mile signal that's important let's diverse groups like investors developers and new permit assures and merchants know that they should be working together to create livable space that the other plays out in technology terms right we're gonna take that 1 metric time from commit to deploy right so if you or an organization that does quarterly releases for example this metric measures the average for every committee had and how long it took to run in production so if you release quarterly that means some commits or made months before it was deployed and maybe some months or some some comments were made minutes before deployment and but the only way that that's going to add up to an average that's measured in minutes is if you change how you develop pictures right you have to start developing features and small patches which means that you need to rethink your development process right maybe you need to launch features . find a feature fi until you have enough of them queued up in production even from the whole thing off the and the change that development method they need to change how development progress is measured and the change how development progress is measured will then you should probably change how your projects are managed and he changed the products are managed the should rethink how objectives are set of Naver rethinking how objects of the set then you're probably in
a position reanalyzed how business decisions are made and that through by and so now you have a situation where that 1 change in engineering rippled all the way through up to the Executive back in time affects everyone in between aligned them in the same direction right that's what these metrics for foreign that's why the leading indicators of change and once you there right in order to keep that metric of being able to deliver changes to production and minutes you probably need some sort of deployment pipeline to start delivering on those metrics of speed and if you're deploying automatically you probably need a series of tests you start going down the path development if you weren't there already which leads to delivering on measures of efficiency and risk and this is how this becomes this self-reinforcing Weber behaviors that all have a way of reinforcing 1 another and the thing about these metrics right is that they don't prescribe exactly which tool to use for which management method to follow they buy it decentralizes knowledge because it conveys and what the priorities are the priorities in this case are shipping sulfur faster safer more reliably and decentralized is the knowledge right because it communicates everyone what the goals are what the metrics are that they need optimized for and what it does is to your teams that grants autonomy grants ownership of the Grantham trust any gives them a direction to know what things you want them to deliver right so rather than defining tens of dozens or hundreds of metrics that prescribed everything along the way instead we focused only on those leading indicators it tells were moving in the right direction so tell me how you measure me and I will tell you how I behave I like to think that a step further and say tell me what all the measures are and I will tell you how the organization I like to think that I'm clever and I came up with that but it turns out it's really to the theory of constraints so start with a holistic set of measurements and align interests across diversity so that's great toward like where do I think that what I do with that in my home on this nations so I just take those metrics and focus only on those but maybe I mean they're pretty good place to start the maybe you care about managing other things in orientation Ireland maybe managing whip limits right work in progress it is important to you because you know that's how you maintain sanity and development when would he do you work that like what's the what indicators usually looking for in that regard the trial and error is really useful when we don't know where we're going I think there's very common advice and off switches experiment and fail quickly and that's really good advice and back that's great advice when developing suffer features and giving them to users and that's great advice in that respect because you can do things like b testing you can see which features are being used which aren't but when we're talking about changing human behavior that's a little bit of a slower process by the thing about failing quickly is the you have to be able to get feedback quickly but the only way you know the the the failed when it comes altering behaviors right 1st the behavior has to be understood and has to be implemented and have to wait a while to see whether or not actually had any effect and maybe be realize that the behavior was actually not implement correctly to go back and iterate teams away the your team's work and that is fundamentally a slow process this feedback loops there are pretty long by nature and the need to be really careful when you start going down that path right you need a little bit more than just pay let's try and see what works and this next part like is part of the by the numbers and because the numbers for why transformation fail our fuzzy at best I think that for a couple reasons regular organizations don't fully understand why things failed or they're still experimenting were to it sometimes organizations are a little reticent to share exactly why the failed and how they failed although dev is there is no learning without sharing I'm but I will say right is that a chat we see this happen a lot there were people start experimenting down the path of what's going to work this was referred to as Dev Ops awakening in a keynote factories use that term here on but that part where teams start experimenting with trial and error to figure out how they think practices they've heard about and how those that into their own organizations but we like to call that operating chasm right and this is when folks this sometimes take the road less traveled and assigned him to have that can be determined as them and just try to see if this thing works right to try something different and when you try something different like maybe you build a flux capacitor or maybe you build brainwave analyzer instead who knows right we hear stories the go both ways on bullets really common here is that when you get into that operational as the what happens is you start thrashing on toolchain choices the start thrashing on workflow decision framing the start fashion on organizational team structures is very common to have a lot of failures because that part of the trial and error process so the learning curve has some clips relatively easy to fall off in the chasm and even the we don't understand why those failures occur you can directly see that they occur in the data right the data reflects this and if you're looking at at the chart earlier there these weird little stats for medium performers and so medium performative basically Dev also weakened teams that started down the path of trial and error and if you look at the performance for failure rates right they're higher than their low-performing counterpart and when things fail they're not necessarily faster and recovery even though will perform can the the right but we see that when you start down that path there's definitely a lot of potential to fall into that did so you tell me draw Grady tell me not to experiment you know like I'm not telling you that all of its important experiment right that's the only way that we learn and that's the only way that we go forward but what I am saying is that we need to compensate for those very long feedback loops so we can avoid potential pitfalls right and and in doing so that's where it's important that systems that we already know work the experiment you basically the scientific method right the scientific method works because we establish a hypothesis before we start the expense and then we go ahead and start the experimentally measured rain figure out whether or not it work but if your experiment is going to run long it's important to make the shock of a hypothesis and you can because you're gonna be living with this experiment for a long time and the best hypotheses start not only with an understanding of the world around you and what the most patterns on questions and luckily in Dev box we we have a lot of empirical data and very common patterns to follow but the best hypotheses also start with an understanding of your current empirical statement like how do you measure where you are today that the only way you can figure out what if it were cannot right what is the delta what is the difference you can we're going if you don't know where you walk and so
how exactly to gather that data and put together a really sharp hypothesis is a little beyond the scope of this talk if you really wanna get into it like by me later and ideas like the last chapter I but I will say this right when you start developing a hypothesis like this for he was going to work in my organization and don't just adopt a practice that you heard in the talk for something that you read the way they were don't just adopted this new tool because you know it works in the sense the you need to have a stronger filter around what the context is and how that will play out the organization that's really important to develop that if you just getting started right the question becomes well how do I develop a really good filter and some terminate and Harvey for this 1 too turn the on the concept of Hari Chinese is a portmanteau 3 words shoe hot we have at the Japanese martial arts constant and that starts with shoe right which means whenever you're learning a new system or process start with the fundamentals right all the traditional wisdom and then once you've followed the traditional wisdom then you get the hot by 1 3rd basics are understood you can break with tradition and forger on that that leads to the re write once you've done that then you can go your in a place where you have mastered the art so if you're just getting started 1 saying all of the known perhaps established the basics and then you're in a better position to start filtering context and figuring out which of those hypotheses will work for you or not so start by taking the road more so the behaviors right so we talk about how we align objectives across a number of teams by using metrics but how we and reinforce that on a day-to-day basis of this quote from and Jacob right the tools we use reinforced behavior the behavior reinforces fools if you want behavior changes to I like to take a step further and say you can't change culture directly but you can change behavior at CERN tools and forced certain behaviors and those certain behaviors or what become your culture the we can still apply Allen how two-way streets work right like you change daily habits of how people get around eventually that leads you to walkable culture that same thing in IT right the role of tools is important in your choices and that's not to say that tools should drive your choice right the key is to pick a set of tools that make you work in ways by default the reinforce those desired behavior right and those desired behavior should work in tandem with the metrics that you've identified so too will reinforce the behaviors the behaviors deliver on those metrics right and those metrics are cheaper out that handling of comes together so what are those tools but I think there is a detail that's pretty often missed whenever we talk about shop on me I'm an ad detail at the philosophy behind why shop on the structured the way that major bombing of the 3 open source projects inspect habitat for shaft and and sick and those are all pretty flexible automation framework that allow you to solve problems in a variety of different ways but shuffle automate the commercial platform is really opinionated about how those all come together the it's really opinionated about how the lock and again because as a platform for the design principle behind shove automate is to create a tool set the changes the daily behaviors of how your teams operate in ways that deliver on proven industry metrics that lead you to success so those metrics right we saw some of those are my thing in the keynote this morning right speed efficiency and risk so we start talking about how a hunger down and make changes in any of these areas of when I talk to you about this everybody wants the focus on speed right go faster and and we can drive faster rate but we don't have set a guard rails we might potentially and up in a ditch and when we start talking it through and figuring out what really matters most folks realize they probably wanna stop by mitigating risk on Easter by mitigating rest then you start delivering on some of the factors behind and service efficiency and then usually lead again at of speed so let's look at them in that order what and there's been a lot of talk on the main stage about compliance automation of hope we've been able attend 1 of the inspectors talks believe that track is still going there you left today if you haven't yet but on stage common Krueger from SAP of reference the tension between development security right are you constantly trading off between speed and rest in the problem here is that you development posturing information security posture most organizations adjust diametrically opposed right in a continuous delivery world all changes managers code to development posture is all about test-driven development right whereas most information security tools just simply are designed with continuous or in mind Brady passed around binders of policy in manual processes right and filling in checklists of results but instead inspect allows information security teams to orient around enabling speed with automation and so inspect allows information security to me developers where they already are right which is code driven continuous delivery uses packs of easily distributed version executable tests that can plug into any tested development work for right so that 1 shift allows both the information in your development teams to align in the same direction although there's there's definitely a lot more that subject on the pretty dense subject and if you want to get into the full length dissertation but but together 19 we witnesses 19 page white paper on it we just published today answer check out or if you just wanna talk about it again here let's talk after this and grab beer tooling around efficiency right tooling around efficiency means looking at service stability and in order to ensure service stability need visibility into all the things that are happening with those underlying layers of automation so that's what some of the uh the changes are that you see the chef are made on the main stage right you need to find the data that you need depending on your function and in an organization so this is why ship on me provides use around what's happening with your nodes right if you're infrastructure person that cares about the state of infrastructure or Compliance Based views that you care about the state of information security and what's happening across your organization you can easily see those errors bubble up to the surface I and when you do see that uh issues bubble up to the surface you need to be able to respond to them quickly and if you started to mitigate issues of risk using automated that compliance tests in stock also deploying remediations very quickly when you identify those issues have risen ran start this leads to things like to detect and correct cycle using inspected chef-client make insert see how this starts a leading into that cohesive work practices
well and what happened there terrier my
clicker is not working there go speed
and so this is the 1 that puts you they care about rape and so on and I'll talk about this quickly uh the shelf on a workflow I think reinforces the need for basic things like a source control right code reviews test-driven development dependency management separation of duties etc. SAP did a really great talk on the using workflow yesterday and so I think that's really to reference it instead here I wanna talk a little bit about the habitat build service those in keynote so the habitat build service you know it's a slightly future facing vision i is basically is still addressing the same basic needs rate I accept risk by making sure that you're in compliance and the you aren't uh guess exposed vulnerabilities along with efficiency right every proper testing all that has been automated in process instead so instead of doing the things manually step by step as you are in today's current workflow right which is codified existing behaviors and made them on that he still have to manually promote artifacts from acceptance into production but otherwise adjust codifies those common but I'm looking at the clock and I'm almost out of time so I was gonna talk about some of the flexibility to maintain this bill our new vision and learning and make a choice of a joke about space there's no but now the time pressure is on in my speaker of literally say joke about base pairs here some is going to go and wrap up instead the so like perspective right the requirement is to weave together a cohesive set of practices then it all lined the the working habits of diverse teams into that you know that cohesive protection against unintended consequences so fundamental philosophy of show me is to do that by default so you have to thinking the you have to do it right not think about managing it just happens for you automatically and this is the default way that you work so the way to succeed in the transformation is to set up those self-reinforcing cycle and again you do that by 1 focusing on a metrics the matter for your organization and to putting tools and place the reinforce those behaviors on a daily basis setting up those self-reinforcing cycles as how distribute expertise right and how you align the needs of teams with different needs and different goals to optimize around the same set of outcomes so reinforcing those behaviors with tooling choices then turns those daily behaviors into 1 eventually becomes your culture and that's the type of approach that scales across even the largest most distributed groups thank you and your time thank
Nachbarschaft <Mathematik>
Zentralisator
Einfügungsdämpfung
Gruppenkeim
Komplex <Algebra>
Datenmanagement
Einheit <Mathematik>
Minimum
Phasenumwandlung
Zentrische Streckung
Nichtlinearer Operator
Ruhmasse
Biprodukt
Rechenschieber
Arithmetisches Mittel
Datenfeld
Forcing
Menge
Rechter Winkel
Projektive Ebene
Programmierumgebung
Aggregatzustand
Telekommunikation
Subtraktion
Kanalkapazität
Selbst organisierendes System
Mathematisierung
Baum <Mathematik>
EDV-Beratung
Zahlenbereich
Transformation <Mathematik>
Transportproblem
Term
Wiederherstellung <Informatik>
Task
Datensatz
Reelle Zahl
Fächer <Mathematik>
Datentyp
Vererbungshierarchie
Datenstruktur
Softwareentwickler
Grundraum
NP-hartes Problem
Videospiel
Linienelement
Transformation <Mathematik>
Linienelement
Mailing-Liste
Fokalpunkt
Quick-Sort
Netzwerktopologie
Flächeninhalt
Dreiecksfreier Graph
Basisvektor
Mereologie
Energiedichte
Boolesche Algebra
Unternehmensarchitektur
Punkt
Gewichtete Summe
Gemeinsamer Speicher
Gruppenkeim
Raum-Zeit
Videokonferenz
Kohäsion
Prozess <Informatik>
Einflussgröße
Gerade
Interpretierer
Softwareentwickler
Cracker <Computerkriminalität>
Kategorie <Mathematik>
Systemaufruf
Prozessautomation
Biprodukt
Entscheidungstheorie
Menge
Rechter Winkel
Projektive Ebene
Schlüsselverwaltung
Arithmetisches Mittel
Aggregatzustand
Nebenbedingung
Subtraktion
Selbst organisierendes System
Mathematisierung
Geräusch
Zahlenbereich
Transformation <Mathematik>
Term
Datensatz
Benutzerbeteiligung
Bildschirmmaske
Arithmetische Folge
Fächer <Mathematik>
Mittelwert
Indexberechnung
Softwareentwickler
Autorisierung
Linienelement
Linienelement
Mathematisierung
Peer-to-Peer-Netz
Frequenz
Quick-Sort
Objekt <Kategorie>
Patch <Software>
Quadratzahl
Hypermedia
Mereologie
Wort <Informatik>
Entropie
Bitrate
Verkehrsinformation
Einfügungsdämpfung
Stellenring
Nebenbedingung
Information
Statistische Hypothese
Richtung
Homepage
Kohäsion
Softwaretest
Mustersprache
Test-First-Ansatz
Computersicherheit
Analytische Fortsetzung
Chi-Quadrat-Verteilung
Auswahlaxiom
Verschiebungsoperator
Softwaretest
Befehl <Informatik>
Dicke
Sichtenkonzept
Computersicherheit
Prognostik
Biprodukt
Bitrate
Kontextbezogenes System
Entscheidungstheorie
Dienst <Informatik>
Menge
Rechter Winkel
Physikalische Theorie
Messprozess
Ordnung <Mathematik>
Fehlermeldung
Orientierung <Mathematik>
Subtraktion
Stabilitätstheorie <Logik>
Selbst organisierendes System
Mathematisierung
Fluss <Mathematik>
Systemplattform
Knotenmenge
Weg <Topologie>
Arithmetische Folge
Flächentheorie
Indexberechnung
Datenstruktur
Soundverarbeitung
Zehn
Open Source
Statistische Analyse
Faktor <Algebra>
Wiederherstellung <Informatik>
Wort <Informatik>
CMM <Software Engineering>
Resultante
Bit
Natürliche Zahl
Versionsverwaltung
Statistische Hypothese
Datenmanagement
Regulärer Graph
Kurvenanpassung
Figurierte Zahl
Default
Einflussgröße
Nichtlinearer Operator
Reihe
Globale Optimierung
Prozessautomation
Checkliste
Teilbarkeit
Projektive Ebene
Information
Schlüsselverwaltung
Prozessautomation
Aggregatzustand
Varietät <Mathematik>
Nebenbedingung
Rückkopplung
Ortsoperator
Quader
Zahlenbereich
Transformation <Mathematik>
Term
Physikalische Theorie
Code
Framework <Informatik>
Fokalpunkt
Inverser Limes
Softwareentwickler
Fundamentalsatz der Algebra
Linienelement
Mathematisierung
Physikalisches System
Frequenz
Fokalpunkt
Quick-Sort
Objekt <Kategorie>
Flächeninhalt
Mereologie
Basisvektor
Dreiecksfreier Graph
Bitrate
Distributionstheorie
Bit
Subtraktion
Selbst organisierendes System
Gruppenkeim
Versionsverwaltung
Transformation <Mathematik>
Code
Raum-Zeit
Kohäsion
Datenmanagement
Perspektive
Test-First-Ansatz
Datentyp
Maschinelles Sehen
Default
Auswahlaxiom
Trennungsaxiom
Softwaretest
Fundamentalsatz der Algebra
Zentrische Streckung
Linienelement
Raum-Zeit
Gebäude <Mathematik>
Strömungsrichtung
Biprodukt
Bitrate
Teilmenge
Druckverlauf
Dienst <Informatik>
Menge
Rechter Winkel
Softwareschwachstelle
Basisvektor
Dreiecksfreier Graph
Prozessautomation

Metadaten

Formale Metadaten

Titel Practical Management of the new Shape of Applications With Chef Automate
Serientitel Chef Conf 2017
Autor Miranda, George
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/34600
Herausgeber Confreaks, LLC
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract DevOps transformation works in seemingly mysterious ways: some organizations thrive like unicorns while others spin their wheels and make little progress. Why do some companies manage to nail it while others struggle to make it past finding the right hammer? There's plenty of conjecture at any conference, so instead let's drop some science. In this talk, we'll look at a wide set of data sources that tell us objectively what works by the numbers. We'll unpack the numbers in those emergent patterns and examine what they mean and what behaviors they represent. We'll also look at how tools shape outcomes and examine what choices make the difference between driving change and struggling to stay afloat. Along the way, we'll look to Chef Automate for examples and we'll break down practical places to dig in if your teams are losing traction.

Ähnliche Filme

Loading...
Feedback