Escenaris en temps real de DevOps: saber què passa en temps real



Aquest bloc parla dels escenaris en temps real de DevOps per ajudar-vos a comprendre els reptes que podeu trobar en temps real i com superar-los.

És possible que molts de vosaltres sigueu conscients de totes les teories relacionades . Però sabeu com implementar els principis de DevOps a la vida real? En aquest bloc, parlaré dels escenaris en temps real de DevOps que us ajudaran a comprendre breument el funcionament de les coses en temps real.

Les indicacions que tractaré en aixòArticle sobre els escenaris en temps real de DevOpssón:





Comencem, doncs, amb el nostre primer tema.

Què és DevOps?

devops-devops escenaris en temps real-EdurekaDevOps és un enfocament de desenvolupament de programari que implica desenvolupament continu, proves contínues, integració contínua, desplegament continu i seguiment continu del programari al llarg del seu cicle de vida de desenvolupament. Aquestes activitats només són possibles a DevOps, no a Agile ni a cascada. És per això que Facebook i altres empreses de primer ordre han escollit DevOps com el camí a seguir per assolir els seus objectius comercials.DevOps es prefereix principalment per desenvolupar programari d'alta qualitat en cicles de desenvolupament més curts, cosa que resulta en una major satisfacció del client.



A la següent secció d’aquestArticle de DevOps Real Time Scenarios, analitzarem els diversos problemes resolts per DevOps.

Problemes resolts per DevOps

1. Entregueu valor als clients

  • DevOps minimitza el temps cal aportar valor als clients. El temps de cicle des que el desenvolupador ha finalitzat una història o tasca fins que la producció es redueix significativament, cosa que permet obtenir el valor el més ràpidament possible.
  • El valor més important obtingut a través de DevOps és que permet a les organitzacions de TI se centren en les seves activitats empresarials 'bàsiques' . En eliminar les limitacions del flux de valor i automatitzar les canonades de desplegament, els equips es poden centrar en les activitats. Això ajuda a crear valor per al client en lloc de moure bits i bytes. Aquestes activitats augmenten l'avantatge competitiu sostenible d'una empresa i creen millors resultats empresarials.



2. Temps de cicle reduït

  • Internament DevOps és l'única manera d'aconseguir l'agilitat per oferir codi segur amb estadístiques. És important tenir portes i un procés DevOps ben elaborat. Quan publiqueu una versió nova, es pot executar paral·lelament amb la versió actual. També podeu comparar mètriques per aconseguir el que volíeu amb mètriques d’aplicació i rendiment.

  • DevOps impulsa els equips de desenvolupament cap a millora contínua i cicles d'alliberament més ràpids . Si es fa bé, aquest procés iteratiu permet centrar-se al llarg del temps en les coses que realment importen. Com ara coses que creen experiències fantàstiques per als usuaris i menys temps en la gestió d’eines, processos i tecnologia.

3. Temps per comercialitzar

El problema més important que es resol és el reducció de la complexitat del procés. Això contribueix significativament a l’èxit del nostre negoci, escurçant el temps de comercialització, donant-nos comentaris ràpids sobre les funcions i fent-nos més sensibles a les necessitats dels nostres clients.

4. Resolució de problemes

  • El valor més important de la implementació amb èxit de DevOps és una major confiança en el lliurament, la visibilitat i la traçabilitat del que passa, de manera que podeu resoldre els problemes més ràpidament.

  • Un altre avantatge important de DevOps és no perdre temps. L’alineació de persones i recursos d’una organització permet implementacions i actualitzacions ràpides. Això permet als programes DevOps solucionar problemes abans que es converteixin en desastres.DevOps crea una cultura de transparència que promou el focus i la col·laboració entre equips de desenvolupament, operacions i seguretat.

CI (Integració contínua) aEscenaris en temps real de DevOps

1. Les persones poden veure la integració contínua contraproduent

Els membres d’un equip de desenvolupament tenen diferents rols, responsabilitats i prioritats. És possible que la primera prioritat del gestor de productes sigui el llançament de noves funcions, ja que el responsable del projecte s’ha d’assegurar que el seu equip compleixi la data límit. Els programadors podrien pensar que si s’aturen per solucionar un error menor cada vegada que es produeixi, l’alentiran. És possible que considerin que la construcció neta és una càrrega addicional per a ells i que no seran els beneficiats pels seus esforços addicionals. Això pot posar en perill el procés d’adaptació.

convertir el doble a enter en java

Per superar-ho:

  • En primer lloc, assegureu-vos que tot l'equip estigui a bord abans d'adoptar una integració contínua.

  • Els CTO i els líders d’equip han d’ajudar els membres de l’equip a comprendre els costos i els beneficis de la integració contínua.

  • Destaqueu què i quan es beneficiaran els programadors dedicant-se a un mètode de treball diferent que requereix una mica més d’obertura i flexibilitat.

2. Integració de CI en el vostre flux de desenvolupament existent

L’adopció d’IC comporta inevitablement la necessitat de canviar essencialment algunes parts del flux de treball de desenvolupament. És possible que els desenvolupadors no solucionin el flux de treball si no es trenca. Això és possible principalment si el vostre equip té una rutina més gran en l’execució del flux de treball actual.

Si voleu canviar el flux de treball, heu de fer-ho amb moltes precaucions. En cas contrari, podria comprometre la productivitat de l’equip de desenvolupament i també la qualitat del producte. Sense el suport suficient de la direcció, l’equip de desenvolupament podria ser una mica reticent a emprendre una tasca amb aquests riscos.

Per superar-ho:

  • Heu d'assegurar-vos que doneu prou temps perquè el vostre equip desenvolupi el seu nou flux de treball. Això es fa per seleccionar una solució d'integració contínua flexible que pugui donar suport al seu nou flux de treball.

  • A més, assegureu-los que l’empresa tingui l’esquena encara que al principi les coses no vagin molt bé.

3. Recaiguda als antics hàbits de proves

L’efecte immediat d’adoptar una integració contínua és que el vostre equip farà proves més sovint. Per tant, més proves necessitaran més casos de prova i escriure casos de prova pot trigar molt de temps. Per tant, els desenvolupadors sovint han de dividir el seu temps entre solucionar errors i escriure casos de prova.

Temporalment, els desenvolupadors podrien estalviar temps fent proves manuals, però a la llarga podrien causar més mal. Com més tardin a escriure casos de prova, més difícil serà recuperar el progrés del desenvolupament. En el pitjor dels casos, és possible que el vostre equip acabi tornant al seu antic procés de proves.

Per superar-ho:

  • Heu de destacar que escriure casos de prova des del principi pot estalviar molt de temps al vostre equip i pot garantir una alta cobertura de proves del vostre producte.

  • A més, incorporeu a la cultura de la vostra empresa la idea que els casos de prova són actius tan valuosos com la mateixa base de codis.

4. Els desenvolupadors ignoren els missatges d'error

És un problema comú que quan equips més grans treballen junts, la quantitat de notificacions CI esdevé aclaparadora i els desenvolupadors comencen a ignorar-les i silenciar-les. Per tant, és possible que es perdin les actualitzacions que els siguin rellevants.

Pot conduir a una etapa en què els codificadors desenvolupen una relativa immunitat a les compilacions trencades i als missatges d'error. Com més temps ignoren les notificacions rellevants, més temps es desenvolupen sense comentaris en la direcció equivocada. Això podria causar enormes reversions, malbaratament de diners, recursos i temps.

Per superar-ho:

  • Només heu d'enviar actualitzacions crítiques.

  • Envieu la notificació només als respectius desenvolupadors que s’encarreguen de solucionar-la.

CT (proves contínues) dinsEscenaris en temps real de DevOps

  1. S'està aconseguint una especificació de requisits correcta

    Si encerteu els vostres requisits, gairebé la meitat de la batalla serà guanyada. Per tant, si teniu una comprensió molt específica i precisa dels requisits, podeu dissenyar millor els plans de prova i cobrir bé els requisits.

    Tot i això, molts equips dediquen molt de temps i esforç a aclarir els requisits. Aquesta és una trampa molt comuna i, per evitar-ho, els equips poden adoptar proves basades en models i tècniques de desenvolupament basat en el comportament. Això ajuda a dissenyar escenaris de prova amb exactitud i adequació.

    Aquestes pràctiques ajudaran definitivament a solucionar i resoldre els buits més ràpidament. A més, els permet generar més casos de prova automàticament des de les primeres etapes d’un sprint.

  2. Orquestració de canonades

    Els avantatges de les proves contínues i lliurament continu estan estretament lligats a l’orquestració de canonades. Això vol dir directament entendre com funciona, per què funciona, com analitzar els resultats i com i quan escalar. Tot depèn de la canalització i, per tant, cal integrar-la amb la suite d'automatització.

    Però el motiu pel qual els equips es barallen és que, cap solució única proporciona la cadena d’eines completa que es necessita per construir un canal de CD.

    Normalment, els equips han de buscar les peces del trencaclosques que siguin correctes per a ells. No hi ha eines perfectes, normalment només les millors, que proporcionen integracions junt amb altres eines. I, per descomptat, una API que també permet integracions fàcils.

    En resum, és impossible implementar proves contínues sense la rapidesa i fiabilitat d’una canonada estandarditzada i automatitzada.

  3. Ampliar i gestionar la complexitat

    Un altre escenari important és que les proves contínues es tornen més complexes a mesura que avança cap a l’entorn de producció. Les proves creixen en nombre, així com en complexitat, amb el codi de maduració i l'entorn cada vegada més complex.

    Heu d'actualitzar les proves cada vegada que actualitzeu diferents fases i scripts automatitzats. Com a resultat, el temps general que es necessita per executar les proves també tendeix a augmentar cap a la versió.

    La solució per a això resideix en una orquestració de proves millorada que proporciona la quantitat adequada de cobertura de prova en cicles de sprint més curts i permet als equips lliurar amb confiança. L’ideal seria que tot el procés s’hagi d’automatitzar amb una TC realitzada en diverses etapes. Per fer-ho, s’utilitzen les portes de la política i la intervenció manual, fins que el codi es porta a la producció.

  4. Creació de bucles de retroalimentació

    Sense bucles de retroalimentació freqüents en totes les etapes del cicle de desenvolupament, no és possible fer proves contínues. Aquesta és en part la raó per la qual és difícil implementar la TC. No només necessiteu proves automatitzades, sinó que també necessiteu visibilitat dels resultats i de l’execució de les proves.

    Els bucles de retroalimentació tradicionals, com ara les eines de registre, els perfils de codi i les eines de control de rendiment, ja no són efectius. Ni treballen junts ni proporcionen la profunditat de la informació necessària per solucionar els problemes. Els taulers de control en temps real que generen informes automàticament i retroalimentació accionable a tota la SDLC ajuden a alliberar el programari més ràpidament a la producció amb defectes menors. L’accés en temps real als taulers i l’accés de tots els membres de l’equip ajuda al mecanisme de retroalimentació contínua.

  5. Manca d’entorns

    La prova contínua significa simplement fer proves més sovint i això requereix colpejar diversos entorns amb més freqüència. Això presenta un coll d'ampolla si els esmentats entorns no estan disponibles en el moment en què es requereixen. Alguns entorns estan disponibles a través d’APIs i d’altres mitjançant diverses interfícies. Alguns d’aquests entorns es poden construir utilitzant arquitectures modernes, mentre que d’altres amb sistemes de mainframe o client / servidor heretats monolítics.

    Però la pregunta aquí és com coordinar les proves a través dels diferents propietaris de l'entorn? També és possible que no sempre mantinguin els entorns en funcionament. La resposta a tot això és Virtualització . Virtualitzant l’entorn, podeu provar el codi sense preocupar-vos massa de les àrees que no canvien.Fer que els entorns siguin accessibles i disponibles sota demanda a través de la virtualització, sens dubte, ajudarà a eliminar un important coll d’ampolla del vostre gasoducte.

CD (lliurament continu) dinsEscenaris en temps real de DevOps

  1. Els desplegaments triguen massa

    Les aplicacions distribuïdes normalment requereixen més que «copiar i enganxar» fitxers en un servidor. La complexitat tendeix a augmentar si teniu una granja de servidors. La incertesa sobre què implementar, on i com és una cosa bastant normal. El resultat? Temps d’espera llargs per aconseguir que els nostres artefactes entrin al proper entorn de la ruta fins a endarrerir-ho tot, fer proves, temps de vida, etc.

    Què aporta DevOps a la taula? Els equips de desenvolupament i operacions de TI defineixen un procés de desplegament en una sessió de col·laboració irreprotxable. Primer, comproven què funciona i després el porten al següent nivell amb automatització per facilitar el lliurament continu. Això redueix dràsticament els temps per al desplegament i també prepara el camí per a desplegaments més freqüents.

  2. Falten artefactes, scripts i altres dependències

    Sovint ens trobem amb errors després del desplegament d’una nova versió d’un programa de treball. Sovint això es produeix perquè no s’actualitzen biblioteques o scripts de base de dades que falten. Això sol ser causat per la manca de claredat sobre les dependències a desplegar i la seva ubicació. Fomentar la col·laboració entre desenvolupament i operacions pot ajudar a resoldre aquest tipus de problemes en la majoria dels casos.

    Quan es tracta d’automatització, podeu definir dependències que ajuden molt a accelerar els desplegaments. Eines de gestió de configuracions com Titella o bé Cap contribuir amb un nivell addicional de definició de dependències. Podem definir no només dependències dins de la nostra aplicació, sinó també a nivell d’infraestructura i configuració de servidor. Per exemple, podem crear una màquina virtual per fer una prova i instal·lar-la / configurar-la tomcat abans de publicar els nostres artefactes.

  3. Supervisió de la producció ineficaç

De vegades, configureu eines de control de manera que es produeixin moltes dades irrellevants de la producció, però altres vegades no produeixen prou ni res. No hi ha una definició de què cal tenir en compte i quines són les mètriques.

Heu d’acord sobre què voleu supervisar i quina informació heu de produir i, a continuació, instal·leu els controls. Les eines de gestió del rendiment de les aplicacions són de gran ajuda si la vostra organització s’ho pot permetre. Mireu AppDynamics, New Relic i AWS X-Ray.

Escenaris de dades DevOps

DevOps es tracta d’eliminar els riscos associats al desenvolupament de programari nou: l’anàlisi de dades identifica aquests riscos. Per mesurar i millorar contínuament el procés DevOps, les analítiques haurien d’abastar-se per tot el gasoducte. Això proporciona informació inestimable sobre la gestió en totes les etapes del cicle de vida del desenvolupament de programari.

1. Menys temps per analitzar dades

Amb totes les dades que es generen en cada moment, les organitzacions han d’acceptar que no ho poden analitzar tot. Simplement, no hi ha prou temps al dia i, malauradament, els robots no són prou sofisticats per fer-ho tot per nosaltres.

Per aquest motiu, és important determinar quins conjunts de dades són més significatius. En la majoria dels casos, això serà diferent per a cada organització. Per tant, abans de capbussar-vos, determineu els objectius i objectius empresarials clau. Normalment, aquests objectius giren al voltant de les necessitats dels clients, principalment les funcions més valuoses que són més importants per als usuaris finals. Per a un minorista, per exemple, a la part superior de la llista s’analitza com interactua el trànsit amb la pàgina de compra del lloc i provant el seu funcionament al fons.

Alguns consells ràpids per identificar quines dades són les més importants per analitzar:

  • Feu un gràfic: determineu l'impacte que tindran les interrupcions a la vostra empresa i feu preguntes com ara 'Si X es trenca , quin efecte tindrà en altres funcions? '

  • Consulteu les dades històriques: identifiqueu on han sorgit problemes en el passat i continueu analitzant les dades de les proves i construïu-les per assegurar-vos que no es repeteixin.

2. Comunicació difícil

Avui en dia, la majoria d’organitzacions encara operen amb diferents equips i persones identificant els seus propis objectius i utilitzant les seves pròpies eines i tecnologies. Cada equip actua de forma independent, es desconnecta de la canonada i es reuneix amb altres equips només durant la fase d’integració.

A l’hora de mirar el panorama més ampli i identificar el que funciona i el que no funciona, l’organització lluita per arribar a una solució. Això es deu sobretot a que tothom no comparteix les dades generals, cosa que fa impossible l’anàlisi.

Per superar aquest problema, reviseu el flux de comunicació per assegurar-vos que tothom col·labora al llarg de l'SDLC, no només durant el procés d'integració.

  • En primer lloc, assegureu-vos que hi hagi una sincronització forta a les mètriques de DevOps des del principi. El progrés de cada equip s’hauria de mostrar en un únic tauler, utilitzant els mateixos indicadors clau de rendiment (KPI) per donar visibilitat a la gestió de tot el procés. Això es fa perquè puguin recopilar totes les dades necessàries per analitzar què va fallar (o què va tenir èxit).

  • Més enllà de la conversa de mètriques inicials, hi hauria d’haver una comunicació constant mitjançant reunions d’equip o canals digitals com Slack.

3. Manca de mà d'obra

Quan tenim poca personalitat, necessitem eines més intel·ligents que facin servir l’aprenentatge profund per incloure les dades que recopilem i prendre decisions ràpidament. Al cap i a la fi, ningú no té temps de mirar cada execució de proves (i per a algunes grans organitzacions, en poden haver-hi uns 75.000 en un dia determinat). El truc és eliminar el soroll i trobar les coses adequades per centrar-se.

Aquí és on la intel·ligència artificial i l’aprenentatge automàtic poden ajudar. Actualment, moltes eines del mercat utilitzen IA i ML per fer coses com:

  • Desenvolupeu scripts i proves per moure i validar diferents dades

  • Informeu de la qualitat basat en comportaments apresos prèviament

  • Treballar en resposta als canvis en temps real.

Així, amb això, hem arribat al final d’aquest article sobre els escenaris en temps real de DevOps.

Ara que ja heu entès què són els escenaris en temps real de DevOps, consulteu això per Edureka, una empresa d'aprenentatge en línia de confiança amb una xarxa de més de 250.000 estudiants satisfets repartits per tot el món. El curs de formació en certificació Edureka DevOps ajuda els estudiants a entendre què és DevOps i obtenir experiència en diversos processos i eines DevOps com Puppet, Jenkins, Nagios, Ansible, Xef, Saltstack i GIT per automatitzar diversos passos en SDLC.

Tens alguna pregunta? Esmenta’l a la secció de comentaris d’aquest documentArticle sobre els escenaris en temps real de DevOpsi ens posarem en contacte amb vosaltres.