Voor degenen die in een DevOps-omgeving werken..

[Joker22]

Hoi,

Voor degenen die op werk in een DevOps team/omgeving zitten..

Ik ben erg benieuwd naar hoe dat allemaal in de praktijk in z'n werk gaat. Ik heb een basic understanding van wat het inhoudt. Developers en Operations die samenwerken om de time-to-market te verlagen en dus een sterke positie in de markt kunnen aanhouden.

Hoe ziet jouw werkomgeving eruit? Wie zitten er allemaal in de team? Zitten jullie in dezelfde kamer?

Hoe ziet het traject voor ontwikkelen (van bijv. een product) eruit? En hoe zit het met het beheer?

Zijn er ook knelpunten die het werk belemmeren? (DevOps wilt verspilling verlagen)

Ik ben erg benieuwd naar jullie ervaringen!

[Blue-eagle]

Joker22 schreef op dinsdag 9 april 2019 @ 11:27:
Hoi,

Voor degenen die op werk in een DevOps team/omgeving zitten..

Ik ben erg benieuwd naar hoe dat allemaal in de praktijk in z'n werk gaat. Ik heb een basic understanding van wat het inhoudt. Developers en Operations die samenwerken om de time-to-market te verlagen en dus een sterke positie in de markt kunnen aanhouden.

Hoe ziet jouw werkomgeving eruit? Wie zitten er allemaal in de team?

Een open office met een paar scrum teams. Ieder team (8 tot 12 mensen) heeft:

• Een of meerdere front-end developers
• Een of meerdere back-end developers
• Een of meerdere testers
• Een of meerdere UX of UI designers
• Een scrum master
• Een product owner
• Mogelijk business intelligence
• Mogelijk een architect of lead

Daarnaast hebben we de operations mensen die eigenlijk over meerdere teams heen bungelen. In dit geval is dat een zelfstandig team van 4 mensen die zich specialiseren in alle CI/CD zaken en taken.

Zitten jullie in dezelfde kamer?

Definieer "kamer" Het is een grote "open office" omgeving maar er staan wel veel muren. Ook glazen wanden.

Hoe ziet het traject voor ontwikkelen (van bijv. een product) eruit?

Dat is een erg brede vraag waar je niet zomaar antwoord op kan geven. Maar we gebruiken Scrum/Kanban en de Agile methodologie voor ons dagelijkse werk. Dat houdt in dat we veel plannen en overleggen, en alles redelijk gestroomlijnd verloopt. Je probeert "waterfall" te voorkomen maar ontkomt er niet aan dat dit som plaatsvindt.

Grofweg:

1. Maak de keuzes voor technologie
2. Bedenk een technisch design & architectuur
3. Grafische vormgeving legt een fundament
4. Technisch fundament wordt ook gelegd
5. Scrum tot het einde der dagen...

En hoe zit het met het beheer?

Dat valt in de omgevingen waarin ik heb gewerkt altijd onder de verantwoordelijkheden van de mensen die er aan werken. Operations (CI/CD) regelen de servers en security, back-end zorgt voor hun databases. Daar zit ook de nodige overlap in; operations kan ook databases optimaliseren, maar dat heeft meer te maken met sharding bijvoorbeeld, niet zozeer met indexes in tabellen.

Zijn er ook knelpunten die het werk belemmeren? (DevOps wilt verspilling verlagen)

Ja, maar persoonlijk merk ik vaak dat vooral Scrum vaak belemmerend werkt. Een kleine feature request levert soms als reactie op: "Oh, dat zullen we inplannen in de volgende sprint, en de sprint daarop kunnen we het misschien meenemen," terwijl ik denk: da's 15 minuten werk, doe het gewoon nu.

Of een bouw-straat die vol hangt met automatische tests voor een deployment. Ja, da's veilig. Maar zodra de software groeit ben je op een gegeven moment 30 minuten bezig voordat je een deployment live krijgt. Deployments zouden altijd selectief moeten testen: test alleen wat daadwerkelijk wordt geraakt door de gemaakte aanpassingen.

Operations en dev/ops zouden altijd moeten streven naar een scenario waar een breaking bug binnen 5 minuten kan worden opgelost. Je moet, vind ik, tientallen keren per dag live kunnen gaan. Ik heb ook gewerkt aan projecten waar je maar 1 keer per 3 maanden live kon gaan...

[shinmeiryu]

Mijn situatie is ook zoals Blue-eagle het beschrijft.
In dit geval met de pech dat we met <10 mensen zitten in één team.

Wij noemen de open office dan een kantoortuin en de team worden niet multi disciplinair behandeld, maar in hun specialisatie. In dit geval 60% product developers, 10% front enders en 30% implementatie.

Bug/features vanuit OPS, wat vrijwel vanuit stakeholders en werkzaamheden komen, worden redelijk snel meegenomen in de product wat DEV dan oppakt.
Kennisdeling is hoog en snel, omdat iedereen betrokken raakt en meegenomen wordt.

Er lopen hele korte lijntjes tussen DEV en OPS, en dat is de grootste voordeel.

Nadelen:
- Omdat er geen scheiding is tussen DEV en OPS, is iedereen inzetbaar op welke vlak dan ook. Meestal wordt er gekozen voor grotendeels OPS.
- Geen concentratie, omdat als je aan DEV werkzaamheden zit, dan wordt je uit de DEV zone gehaald om terug te gaan naar de OPS zone.
- In scrum is er zoveel gedoe over velocity. Wij hebben onze board gesplitst in DEV en OPS werkzaamheden voor het overzicht, maar dan is het maar net wie wat gaat doen.
- Het is een rollenspel. Ik zelf vind het onhandig dat je op één dag constant van petje moet wisselen.

Devops heeft een hele mooie principe, maar als het bedrijf kiest voor billable werk, dan kun je de Dev wegkrassen en heeft OPS nu meer tijd gekregen voor de mensen die weinig tot geen OPS werk heeft gedaan.

Ik ben zelf ook wel benieuwd hoe anderen dit ervaren. Voor mij valt het tegen.

[Joker22]

Blue-eagle schreef op dinsdag 9 april 2019 @ 12:28:
[...]


Een open office met een paar scrum teams. Ieder team (8 tot 12 mensen) heeft:

• Een of meerdere front-end developers
• Een of meerdere back-end developers
• Een of meerdere testers
• Een of meerdere UX of UI designers
• Een scrum master
• Een product owner
• Mogelijk business intelligence
• Mogelijk een architect of lead

Daarnaast hebben we de operations mensen die eigenlijk over meerdere teams heen bungelen. In dit geval is dat een zelfstandig team van 4 mensen die zich specialiseren in alle CI/CD zaken en taken.


[...]


Definieer "kamer" Het is een grote "open office" omgeving maar er staan wel veel muren. Ook glazen wanden.


[...]


Dat is een erg brede vraag waar je niet zomaar antwoord op kan geven. Maar we gebruiken Scrum/Kanban en de Agile methodologie voor ons dagelijkse werk. Dat houdt in dat we veel plannen en overleggen, en alles redelijk gestroomlijnd verloopt. Je probeert "waterfall" te voorkomen maar ontkomt er niet aan dat dit som plaatsvindt.

Grofweg:

1. Maak de keuzes voor technologie
2. Bedenk een technisch design & architectuur
3. Grafische vormgeving legt een fundament
4. Technisch fundament wordt ook gelegd
5. Scrum tot het einde der dagen...

[...]


Dat valt in de omgevingen waarin ik heb gewerkt altijd onder de verantwoordelijkheden van de mensen die er aan werken. Operations (CI/CD) regelen de servers en security, back-end zorgt voor hun databases. Daar zit ook de nodige overlap in; operations kan ook databases optimaliseren, maar dat heeft meer te maken met sharding bijvoorbeeld, niet zozeer met indexes in tabellen.


[...]


Ja, maar persoonlijk merk ik vaak dat vooral Scrum vaak belemmerend werkt. Een kleine feature request levert soms als reactie op: "Oh, dat zullen we inplannen in de volgende sprint, en de sprint daarop kunnen we het misschien meenemen," terwijl ik denk: da's 15 minuten werk, doe het gewoon nu.

Of een bouw-straat die vol hangt met automatische tests voor een deployment. Ja, da's veilig. Maar zodra de software groeit ben je op een gegeven moment 30 minuten bezig voordat je een deployment live krijgt. Deployments zouden altijd selectief moeten testen: test alleen wat daadwerkelijk wordt geraakt door de gemaakte aanpassingen.

Operations en dev/ops zouden altijd moeten streven naar een scenario waar een breaking bug binnen 5 minuten kan worden opgelost. Je moet, vind ik, tientallen keren per dag live kunnen gaan. Ik heb ook gewerkt aan projecten waar je maar 1 keer per 3 maanden live kon gaan...

toon volledige bericht

Is het niet zo dat testers niet echt nodig zijn in een DevOps team omdat bijna alles geautomatiseerd getest wordt?

Daarnaast hebben we de operations mensen die eigenlijk over meerdere teams heen bungelen. In dit geval is dat een zelfstandig team van 4 mensen die zich specialiseren in alle CI/CD zaken en taken.

Dus in dit geval is Operations gewoon een team van 4 mensen die in dezelfde omgeving bevinden en daarmee dus directe contact hebben met alle scrum teams?

[Joker22]

shinmeiryu schreef op dinsdag 9 april 2019 @ 13:00:
Mijn situatie is ook zoals Blue-eagle het beschrijft.
In dit geval met de pech dat we met <10 mensen zitten in één team.

Wij noemen de open office dan een kantoortuin en de team worden niet multi disciplinair behandeld, maar in hun specialisatie. In dit geval 60% product developers, 10% front enders en 30% implementatie.

Bug/features vanuit OPS, wat vrijwel vanuit stakeholders en werkzaamheden komen, worden redelijk snel meegenomen in de product wat DEV dan oppakt.
Kennisdeling is hoog en snel, omdat iedereen betrokken raakt en meegenomen wordt.

Er lopen hele korte lijntjes tussen DEV en OPS, en dat is de grootste voordeel.

Nadelen:
- Omdat er geen scheiding is tussen DEV en OPS, is iedereen inzetbaar op welke vlak dan ook. Meestal wordt er gekozen voor grotendeels OPS.
- Geen concentratie, omdat als je aan DEV werkzaamheden zit, dan wordt je uit de DEV zone gehaald om terug te gaan naar de OPS zone.
- In scrum is er zoveel gedoe over velocity. Wij hebben onze board gesplitst in DEV en OPS werkzaamheden voor het overzicht, maar dan is het maar net wie wat gaat doen.
- Het is een rollenspel. Ik zelf vind het onhandig dat je op één dag constant van petje moet wisselen.

Devops heeft een hele mooie principe, maar als het bedrijf kiest voor billable werk, dan kun je de Dev wegkrassen en heeft OPS nu meer tijd gekregen voor de mensen die weinig tot geen OPS werk heeft gedaan.

Ik ben zelf ook wel benieuwd hoe anderen dit ervaren. Voor mij valt het tegen.

toon volledige bericht

Werkzaamheden van dev en ops horen elkaar te ondersteunen en te versterken door samenwerken toch. Is het niet zo dat dat developers gewoon developers zijn en operations gewoon operations? Het is niet de bedoeling dat jullie elkaars werk doen toch, of is het zo dat iedereen breed is gespecialiseerd bij jullie ?

[Hydra]

Joker22 schreef op dinsdag 9 april 2019 @ 13:03:
Is het niet zo dat testers niet echt nodig zijn in een DevOps team omdat bijna alles geautomatiseerd getest wordt?

Dat heeft an sich weinig met DevOps te maken. Of je nu "DevOps" doet of niet; vergevorderde automatisering is een onderdeel van een volwassen software engineering niveau. Maar er zijn vrij vaak dingen die lastig te automatiseren zijn. En dan zijn testers die niet na 3 keer gek worden van hetzelfde script doorlopen wel handig

Joker22 schreef op dinsdag 9 april 2019 @ 13:07:
Werkzaamheden van dev en ops horen elkaar te ondersteunen en te versterken door samenwerken toch. Is het niet zo dat dat developers gewoon developers zijn en operations gewoon operations?

Als het goed is wel. Helaas zijn er veel bedrijven die de term misbruiken om Devs meer Ops werk te laten doen om zo op Ops capaciteit te kunnen besparen. Dan heb je uiteindelijk op een team van 20 devs 1/2 Ops mensen die compleet overwerkt zijn.

[ Voor 33% gewijzigd door Hydra op 09-04-2019 13:12 ]

[Blue-eagle]

Joker22 schreef op dinsdag 9 april 2019 @ 13:03:
[...]


Is het niet zo dat testers niet echt nodig zijn in een DevOps team omdat bijna alles geautomatiseerd getest wordt?

Met testers bedoel ik vooral de mensen die de software uitvoerig testen op meerdere omgevingen voor livegang. Meestal volgt men een (L)DTAP proces: (Local), Development, Testing, Acceptance, Production.

• Op LOC (localhost) werken developers aan de code en voeren ze hun unit tests uit voor iedere commit of push op hun branch(es).
• Op DEV zie je het creatuur wat developers bij elkaar weten te smeden. Hier klikken developers zelf rond om te kijken of de applicatie connected met een DEV backend nog gewoon werkt of niet. Hier wonen talloze gebruikers en producten met de naam "asdasdasd", en natuurlijk little Bobby Tables
• Op TST zie je iets wat met UI en integratietests kan worden getest. Hier voeren testers uitgebreid hun geautomatiseerde test suites op uit.
• En op ACC heb je een 1 op 1 live omgeving draaien maar waarmee nooit echte gebruikers worden geraakt. In ons geval is dit een regelrechte kloon van de live omgeving, alleen alle outgoing communicatie zoals e-mail wordt verstuurd naar een interne catch-all mailbox. Hier draaien alsnog alle UI, E2E, integratie, unit en andere tests, waarna...
• ...op PRD alles als het goed is gewoon stabiel is en werkt.

[...]


Dus in dit geval is Operations gewoon een team van 4 mensen die in dezelfde omgeving bevinden en daarmee dus directe contact hebben met alle scrum teams?

Nouja, ze zitten in hun eigen hoekje achter een muur waar fietsen hangen te doen alsof ze heel druk zijn de hele dag. Ze hebben alle monitors tactisch richting een muur gedraaid zodat niemand ziet wat ze doen. Wij zijn er van overtuigd dat ze veel tijd kwijt zijn aan Netflix, Civ 5 en Cities Skylines. Zij zijn tevens de mensen die in de gaten houden dat niemand het netwerk misbruikt, dus... tja.

Maar alles draait stabiel, en zodra d'r iets omvalt staan ze er ook. Soms ook tot diep in de nacht, zeker als wij iets nodig hebben wat downtime tot gevolg heeft. Dat willen we op dalmomenten doen (dus na middernacht).

Maar, ja. Ze hebben contact met de scrum teams, erg ad-hoc. Als wij iets nodig hebben zijn ze bereikbaar.

[Joker22]

Oke duidelijk, bedankt allen voor jullie antwoord. Als er nog meer reacties komen, altijd welkom !

[drooger]

Joker22 schreef op dinsdag 9 april 2019 @ 11:27:
Hoe ziet jouw werkomgeving eruit? Wie zitten er allemaal in de team? Zitten jullie in dezelfde kamer?

Bij een vorige baan was het een mix van developers, ops engineers, solution architects en een tester.
Allemaal in dezelfde hoek van het pand.

Hoe ziet het traject voor ontwikkelen (van bijv. een product) eruit? En hoe zit het met het beheer?

Voor developen is het het standaard traject van laptop/vm -> OTAP-straat, maar wel geholpen door tools zodat je code automatisch uitgerold wordt na een commit en t/m Acceptatie automatisch getest wordt.
Pas voor productie moet je handmatig akkoord geven voor uitrol.

Voor beheer is het de taak om de omgevingen zoveel mogelijk gelijk, flexibel en opnieuw uitrolbaar te houden, veelal met behulp van IaC (Infrastructure as Code).
Je wilt zo min mogelijk handmatige stappen hierin hebben en dat geldt ook voor allerlei andere acties zoals server herstarts, switchen naar je DR-omgeving etc.

Zijn er ook knelpunten die het werk belemmeren? (DevOps wilt verspilling verlagen)

• Systemen die er zich niet toe lenen, maar gelukkig is dit gaandeweg steeds minder het geval.
• Niet open staan voor (nieuwe/andere) tooling, bijv. door budget, policy, "wildgroei aan tooling".
• Mindset !!! Sommige mensen blijven hangen in het oude denken en gaan elke twee dagen servers herstarten i.p.v. oplossingen hiervoor te zoeken.
• Capabiliteit, zaken automatiseren moet je op een slimme manier doen en niet met "houtje-touwtje"-scripts.
• Tijd, je moet vanuit wel tijd hebben of het mandaat krijgen om tijd te besteden aan verbeteringen.