Velen van jullie zijn misschien op de hoogte van alle theorieën die hiermee verband houden . Maar weet jij hoe je DevOps-principes in het echte leven implementeert? In deze blog bespreek ik de DevOps Real Time-scenario's die je zullen helpen een kort inzicht te krijgen in hoe dingen in realtime werken.
De aanwijzingen die ik hierin zal behandelenDevOps Real Time Scenarios-artikelzijn:
- Wat is DevOps?
- Problemen opgelost door DevOps
- CI-scenario's (continue integratie)
- CT-scenario's (continu testen)
- Cd-scenario's (continue levering)
- DevOps-gegevensscenario's
Dus laten we beginnen met ons eerste onderwerp.
Wat is DevOps?
DevOps is een benadering van softwareontwikkeling die continue ontwikkeling, continu testen, continue integratie, continue implementatie en continue monitoring van de software omvat gedurende de ontwikkelingscyclus. Deze activiteiten zijn alleen mogelijk in DevOps, niet Agile of waterval. Daarom hebben Facebook en andere topbedrijven DevOps gekozen als de weg voorwaarts voor hun zakelijke doelen.DevOps heeft vooral de voorkeur voor het ontwikkelen van hoogwaardige software in kortere ontwikkelcycli wat resulteert in een grotere klanttevredenheid.
In de volgende sectie hiervanDevOps Real Time Scenarios-artikel, zullen we de verschillende problemen bekijken die door DevOps zijn opgelost.
verschil tussen jQuery en javascript
Problemen opgelost door DevOps
1. Lever waarde aan klanten
- DevOps minimaliseert de tijd er is nodig om waarde te leveren aan klanten. De cyclustijd vanaf de voltooiing van een verhaal / taak door de ontwikkelaar tot de productie neemt aanzienlijk af, waardoor de waarde zo snel mogelijk kan worden gerealiseerd.
De belangrijkste waarde die met DevOps wordt gerealiseerd, is dat IT-organisaties dat kunnen focus op hun 'kern' zakelijke activiteiten . Door beperkingen binnen de waardestroom weg te nemen en implementatiepijplijnen te automatiseren, kunnen teams zich concentreren op de activiteiten. Dit helpt bij het creëren van klantwaarde in plaats van alleen bits en bytes te verplaatsen. Deze activiteiten vergroten het duurzame concurrentievoordeel van een bedrijf en zorgen voor betere bedrijfsresultaten.
2. Kortere cyclustijd
Intern is DevOps de enige manier om de flexibiliteit te bereiken om veilige code met inzichten te leveren. Het is belangrijk om poorten en een goed doordacht DevOps-proces te hebben. Wanneer u een nieuwe versie levert, kan deze naast de huidige versie worden uitgevoerd. U kunt metrische gegevens ook vergelijken om te bereiken wat u wilde met metrische gegevens voor toepassingen en prestaties.
DevOps drijft ontwikkelingsteams naar continue verbetering en snellere release-cycli . Als het goed wordt gedaan, zorgt dit iteratieve proces voor meer focus in de tijd, op de dingen die er echt toe doen. Zoals dingen die geweldige ervaringen voor gebruikers creëren - en minder tijd aan het beheren van tools, processen en technologie.
3. Time to market
Het belangrijkste probleem dat wordt opgelost, is de vermindering van de complexiteit van het proces. Dit draagt aanzienlijk bij aan het succes van ons bedrijf door onze time-to-market te verkorten, ons snel feedback te geven over functies en ons beter te laten reageren op de behoeften van onze klanten.
4. Probleemoplossing
De grootste waarde van een succesvolle DevOps-implementatie is een groter vertrouwen in levering, zichtbaarheid en traceerbaarheid naar wat er aan de hand is, zodat u problemen sneller kunt oplossen.
Een ander belangrijk voordeel van DevOps is dat je geen tijd verspilt. Door de mensen en middelen van een organisatie op elkaar af te stemmen, zijn snelle implementaties en updates mogelijk. Hierdoor kunnen DevOps-programma's problemen oplossen voordat ze een ramp worden.DevOps creëert een cultuur van transparantie die focus en samenwerking tussen ontwikkelingsteams, operationele teams en beveiligingsteams bevordert.
CI (continue integratie) inDevOps realtime scenario's
1. Individuen kunnen voortdurende integratie als contraproductief beschouwen
Leden van een ontwikkelteam hebben verschillende rollen, verantwoordelijkheden en prioriteiten. Het is mogelijk dat de eerste prioriteit van de productmanager het lanceren van nieuwe functies is, projectmanagers moeten ervoor zorgen dat hun team de deadline haalt. Programmeurs denken misschien dat als ze stoppen om een kleine bug op te lossen elke keer dat deze zich voordoet, ze zullen vertragen. Ze kunnen het gevoel hebben dat het schoonhouden van het gebouw een extra last voor hen is en dat ze niet zullen profiteren van hun extra inspanningen. Dit kan het aanpassingsproces mogelijk in gevaar brengen.
Om dit te verhelpen:
Zorg er allereerst voor dat uw hele team aan boord is voordat u overgaat tot continue integratie.
CTO's en teamleiders moeten de teamleden helpen de kosten en baten van continue integratie te begrijpen.
Benadruk wat en wanneer codeerders zullen profiteren door zich in te zetten voor een andere werkwijze die wat meer openheid en flexibiliteit vereist.
2. CI integreren in uw bestaande ontwikkelingsstroom
Het adopteren van CI komt onvermijdelijk met de noodzaak om in wezen sommige delen van uw ontwikkelingsworkflow te veranderen. Het is mogelijk dat uw ontwikkelaars de workflow niet herstellen als deze niet kapot is. Dit is vooral mogelijk als uw team een grotere routine heeft bij het uitvoeren van hun huidige workflow.
Als u de workflow wilt wijzigen, moet u dit met grote voorzorgsmaatregelen doen. Anders kan het de productiviteit van het ontwikkelingsteam en ook de kwaliteit van het product in gevaar brengen. Zonder voldoende steun van de leiding kan het ontwikkelteam een beetje terughoudend zijn om een taak op zich te nemen die dergelijke risico's met zich meebrengt.
Om dit te verhelpen:
U moet ervoor zorgen dat u uw team voldoende tijd geeft om hun nieuwe workflow te ontwikkelen. Dit wordt gedaan om een flexibele oplossing voor continue integratie te selecteren die hun nieuwe workflow kan ondersteunen.
Zorg er ook voor dat het bedrijf hun rug toekeert, zelfs als het in het begin misschien niet zo soepel gaat.
3. Terugval naar de vroegere testgewoonten
Het directe effect van continue integratie is dat uw team vaker gaat testen. Voor meer tests zijn dus meer testcases nodig en het schrijven van testcases kan tijdrovend zijn. Daarom moeten ontwikkelaars hun tijd vaak verdelen tussen het oplossen van bugs en het schrijven van testcases.
Tijdelijk kunnen ontwikkelaars tijd besparen door handmatig te testen, maar op de lange termijn kan het meer pijn doen. Hoe meer ze het schrijven van testcases uitstellen, hoe moeilijker het wordt om de voortgang van de ontwikkeling in te halen. In het ergste geval kan uw team uiteindelijk terugkeren naar hun oude testproces.
Om dit te verhelpen:
U moet benadrukken dat het schrijven van testcases vanaf het begin uw team veel tijd kan besparen en een hoge testdekking van uw product kan garanderen.
Veranker ook het idee in uw bedrijfscultuur dat testcases net zo waardevol zijn als de codebase zelf.
4. Ontwikkelaars negeren foutmeldingen
Het is een veelvoorkomend probleem dat wanneer grotere teams samenwerken, het aantal CI-meldingen overweldigend wordt en ontwikkelaars deze gaan negeren en dempen. Daarom is het mogelijk dat ze de updates missen die voor hen relevant zijn.
Het kan leiden tot een fase waarin codeerders een relatieve immuniteit ontwikkelen voor kapotte builds en foutmeldingen. Hoe langer ze relevante meldingen negeren, hoe langer ze zich ontwikkelen zonder feedback in de verkeerde richting. Dit kan mogelijk enorme terugdraaiingen en verspilling van geld, middelen en tijd veroorzaken.
Om dit te verhelpen:
Stuur alleen kritieke updates.
Stuur de melding alleen naar de respectievelijke ontwikkelaars die verantwoordelijk zijn voor het oplossen ervan.
CT (continu testen) inDevOps realtime scenario's
Vereisten specificatie goed krijgen
Als je aan je eisen voldoet, is bijna de helft van de strijd gewonnen. Dus als u een zeer specifiek en nauwkeurig begrip van de vereisten heeft, kunt u testplannen beter ontwerpen en de vereisten goed dekken.
Toch besteden veel teams veel tijd en moeite aan het simpelweg verduidelijken van de vereisten. Dit is een veel voorkomende valkuil en om dit te voorkomen, kunnen teams Model-based testing en Behavior-Driven Development-technieken toepassen. Dit helpt om testscenario's nauwkeurig en adequaat te ontwerpen.
Deze praktijken zullen zeker helpen om de hiaten sneller aan te pakken en op te lossen. Het stelt hen ook in staat om automatisch meer testcases te genereren vanaf de vroege stadia van een sprint.
Pipeline-orkestratie
De voordelen van continu testen en continue levering zijn nauw verbonden met pijplijnorkestratie. Dit betekent direct dat u begrijpt hoe het werkt, waarom het werkt, hoe u de resultaten kunt analyseren en hoe en wanneer u kunt opschalen. Alles hangt af van de pijplijn en daarom moet u de pijplijn integreren met de automatiseringssuite.
Maar de reden waarom teams worstelen, is dat geen enkele oplossing de volledige toolchain biedt die nodig is om een CD-pijplijn op te bouwen.
Teams moeten doorgaans zoeken naar de stukjes van de puzzel die voor hen geschikt zijn. Er zijn geen perfecte tools, meestal alleen de beste tools, die samen met meerdere andere tools integraties bieden. En natuurlijk een API die ook eenvoudige integraties mogelijk maakt.
voer een hive-query uit vanaf de opdrachtregel
Kortom, het is onmogelijk om continu testen te implementeren zonder de snelheid en betrouwbaarheid van een gestandaardiseerde en geautomatiseerde pijplijn.
Opschalen en managen van complexiteit
Een ander belangrijk scenario is dat continu testen ingewikkelder wordt naarmate het naar de productieomgeving gaat. De tests groeien zowel in aantal als in complexiteit naarmate de volwassen wordende code en de omgeving complexer worden.
Elke keer dat u verschillende fasen en geautomatiseerde scripts bijwerkt, moet u tests bijwerken. Als gevolg hiervan neigt de totale tijd die nodig is om de tests uit te voeren ook naar de release.
De oplossing hiervoor ligt in verbeterde testorkestratie die de juiste hoeveelheid testdekking biedt in kortere sprintcycli en teams in staat stelt met vertrouwen te presteren. Idealiter moet het hele proces worden geautomatiseerd met CT die in verschillende fasen wordt uitgevoerd. Dit wordt gedaan met behulp van beleidspoorten en handmatige tussenkomst, totdat de code naar productie wordt gepusht.
Feedbackloops creëren
Zonder frequente feedbackloops in elke fase van de ontwikkelingscyclus, is continu testen niet mogelijk. Dit is gedeeltelijk de reden waarom CT moeilijk te implementeren is. Je hebt niet alleen geautomatiseerde tests nodig, maar je hebt ook zichtbaarheid van de testresultaten en uitvoering nodig.
Traditionele feedbackloops zoals loggingtools, codeprofilers en prestatiebewakingstools zijn niet meer effectief. Ze werken niet samen en bieden ook niet het diepgaande inzicht dat nodig is om problemen op te lossen. Realtime dashboards die automatisch rapporten genereren en bruikbare feedback over de hele SDLC genereren, helpen software sneller in productie te brengen met minder defecten. Realtime toegang tot dashboards en toegang voor alle teamleden helpt het continue feedbackmechanisme.
Gebrek aan omgevingen
Continu testen betekent simpelweg vaker testen en hiervoor moeten meerdere omgevingen vaker worden aangeraakt. Dit levert een bottleneck op als de genoemde omgevingen niet beschikbaar zijn op het moment dat ze nodig zijn. Sommige omgevingen zijn beschikbaar via API's en andere via verschillende interfaces. Sommige van deze omgevingen kunnen worden gebouwd met behulp van moderne architectuur, terwijl andere met monolithische legacy client / server- of mainframesystemen.
Maar de vraag is hier: hoe coördineer je het testen via de verschillende omgevingseigenaren? Het is ook mogelijk dat ze de omgevingen niet altijd draaiende houden. Het antwoord op dit alles is Virtualisatie . Door de omgeving te virtualiseren, kunt u de code testen zonder u al te veel zorgen te maken over onveranderlijke gebieden.Door de omgevingen op aanvraag toegankelijk en beschikbaar te maken via virtualisatie, helpt dit zeker om een significant knelpunt uit uw pijplijn te verwijderen.
CD (continue levering) inDevOps realtime scenario's
Implementaties duren te lang
Voor gedistribueerde applicaties is normaal gesproken meer nodig dan het ‘kopiëren en plakken’ van bestanden naar een server. De complexiteit neemt doorgaans toe als u een serverfarm heeft. Onzekerheid over wat te implementeren, waar en hoe, is vrij normaal. Het resultaat? Lange wachttijden om onze artefacten in de volgende omgeving van de route te krijgen om alles uit te stellen, testen, tijd om te leven, enz.
Wat brengt DevOps naar de tafel? Ontwikkelings- en IT-operatieteams definiëren een implementatieproces in een onberispelijke samenwerkingssessie. Eerst verifiëren ze wat werkt en tillen ze het vervolgens naar een hoger niveau met automatisering om continue levering mogelijk te maken. Dit verkort de timing voor implementatie drastisch en maakt ook de weg vrij voor frequentere implementaties.
Ontbrekende artefacten, scripts en andere afhankelijkheden
We komen regelmatig fouten tegen na de implementatie van een nieuwe versie van een werkend stuk software. Dit wordt vaak veroorzaakt doordat bibliotheken ontbreken of databasescripts niet worden bijgewerkt. Dit wordt meestal veroorzaakt door onduidelijkheid over welke afhankelijkheden moeten worden ingezet en hun locatie. Door samenwerking tussen ontwikkeling en bedrijfsvoering te bevorderen, kunnen dit soort problemen in de meeste gevallen worden opgelost.
Als het op automatisering aankomt, kunt u afhankelijkheden definiëren die veel helpen bij het versnellen van implementaties. Configuratiebeheertools zoals Marionet of Chef bijdragen met een extra definitie van afhankelijkheden. We kunnen niet alleen afhankelijkheden binnen onze applicatie definiëren, maar ook op het niveau van infrastructuur en serverconfiguratie. We kunnen bijvoorbeeld een virtuele machine maken voor een test en deze installeren / configureren kater voordat onze artefacten worden gepubliceerd.
Ineffectieve productiebewaking
Soms configureert u monitoringtools op een manier die veel irrelevante gegevens uit de productie produceert, maar soms produceren ze niet genoeg of helemaal niets. Er is geen definitie van waar u op moet letten en wat de statistieken zijn.
U moet afspreken wat u wilt controleren en welke informatie u moet produceren, en vervolgens moet u maatregelen nemen. Application Performance managementtools zijn een grote hulp als uw organisatie het zich kan veroorloven, kijk eens naar AppDynamics, New Relic en AWS X-Ray.
DevOps-gegevensscenario's
Bij DevOps draait alles om het elimineren van de risico's die gepaard gaan met de ontwikkeling van nieuwe software: data-analyse identificeert die risico's. Om het DevOps-proces continu te meten en te verbeteren, moeten analyses zich over de hele pijplijn uitstrekken. Dit biedt onschatbare inzichten voor het management in alle stadia van de levenscyclus van softwareontwikkeling.
1. Minder tijd om gegevens te analyseren
Met alle gegevens die op een bepaald moment worden gegenereerd, moeten organisaties accepteren dat ze niet alles kunnen analyseren. Er is gewoon niet genoeg tijd op de dag - en helaas zijn robots nog niet zo geavanceerd genoeg om het allemaal voor ons te doen.
Om die reden is het belangrijk om te bepalen welke datasets het meest significant zijn. In de meeste gevallen zal dit voor elke organisatie anders zijn. Bepaal dus voordat u erin duikt de belangrijkste zakelijke doelstellingen en doelen. Meestal draaien deze doelen om de behoeften van de klant - in de eerste plaats de meest waardevolle functies die het belangrijkst zijn voor eindgebruikers. Voor een detailhandelaar staat bijvoorbeeld het analyseren van hoe verkeer omgaat met de afrekenpagina op de site en het testen hoe het werkt in de back-end bovenaan de lijst.
Enkele snelle tips om te bepalen welke gegevens het belangrijkst zijn om te analyseren:
Maak een diagram: bepaal de impact die uitval op uw bedrijf zal hebben, door vragen te stellen als: 'If X breekt , welk effect heeft het op andere functies? '
Bekijk historische gegevens: identificeer waar problemen zich in het verleden hebben voorgedaan en blijf gegevens van tests analyseren en bouwen om ervoor te zorgen dat dit niet opnieuw gebeurt.
2. Moeilijke communicatie
Tegenwoordig werken de meeste organisaties nog steeds met verschillende teams en persona's die hun eigen doelen identificeren en hun eigen tools en technologieën gebruiken. Elk team handelt onafhankelijk, losgekoppeld van de pijplijn en vergadert alleen met andere teams tijdens de integratiefase.
Als het erom gaat naar het grotere plaatje te kijken en te identificeren wat wel en niet werkt, worstelt de organisatie om tot één oplossing te komen. Dit komt vooral omdat niet iedereen de algemene gegevens deelt, waardoor analyse onmogelijk wordt.
Om dit probleem op te lossen, moet u de communicatiestroom herzien om ervoor te zorgen dat iedereen in de hele SDLC meewerkt, niet alleen tijdens het integratieproces.
Zorg er eerst voor dat DevOps-statistieken vanaf het begin goed worden gesynchroniseerd. De voortgang van elk team moet worden weergegeven in één dashboard, met behulp van dezelfde Key Performance Indicators (KPI's) om het management inzicht te geven in het hele proces. Dit wordt gedaan zodat ze alle benodigde gegevens kunnen verzamelen om te analyseren wat er mis ging (of wat erin is geslaagd).
Naast het eerste metrics-gesprek, moet er constant worden gecommuniceerd via teamvergaderingen of digitale kanalen zoals Slack.
3. Gebrek aan mankracht
Als we te weinig personeel hebben, hebben we slimmere tools nodig die deep learning gebruiken om de gegevens die we verzamelen in te voegen en snel tot beslissingen te komen. Niemand heeft immers tijd om naar elke testuitvoering te kijken (en voor sommige grote organisaties kunnen dat er op een dag ongeveer 75.000 zijn). De truc is om de ruis te elimineren en de juiste dingen te vinden om op te focussen.
Dit is waar kunstmatige intelligentie en machine learning kunnen helpen. Veel tools die tegenwoordig op de markt zijn, gebruiken AI en ML om dingen te doen zoals:
Ontwikkel scripts en tests om verschillende soorten gegevens te verplaatsen en valideren
Rapporteer over kwaliteit op basis van eerder aangeleerd gedrag
Werk in reactie op realtime veranderingen.
Hiermee zijn we dus aan het einde gekomen van dit artikel over DevOps Real Time Scenarios.
Nu je hebt begrepen wat DevOps Real Time Scenarios zijn, kun je dit eens bekijken door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld. De Edureka DevOps Certification Training-cursus helpt leerlingen te begrijpen wat DevOps is en expertise op te doen in verschillende DevOps-processen en -tools zoals Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack en GIT voor het automatiseren van meerdere stappen in SDLC.
Heeft u een vraag voor ons? Gelieve dit te vermelden in het commentaargedeelte hiervanDevOps Real Time Scenarios-artikelen we nemen zo snel mogelijk contact met u op.