Als DevOps consultants en Azure DevOps specialisten komen wij regelmatig bij kleine en grote organisaties die werken met Azure DevOps. Vaak krijgen wij de vraag wat nu een ‘Azure DevOps Project’ is en hoe dit gebruikt kan worden om een organisatie te moduleren.
Azure DevOps projecten
Binnen Azure DevOps is een project niet persé een project zoals we deze kennen binnen projectmanagement maar het is primair een security afbakening. Meerdere teams kunnen binnen een project werken aan meerdere producten of applicaties. Microsoft legt op deze pagina het volgende uit:
"Een project in Azure DevOps biedt gebruikers een plek om de voortgang te plannen, bij te houden en samen te werken aan het bouwen van softwareoplossingen. Een project vertegenwoordigt een fundamentele container waarin u gegevens en broncode kunt opslaan."
Primair is het een security afbakening en zorgt ervoor dat gegevens zijn geïsoleerd. Toegang tot Project A wil niet zeggen dat je als ontwikkelaar toegang hebt tot Project B. Binnen elk project zijn er ook standaard Azure DevOps rollen zoals Reader, Contributor en Project Administrator. Custom rollen zijn binnen een project aan te maken en entiteiten - zoals pipelines en repositories - kunnen binnen een project afgeschermd worden maar in de praktijk is dit geen sinecure.
Hoe richt je een Azure DevOps omgeving in?
Als we een nieuwe Azure DevOps omgeving aanmaken
of klanten helpen met de vraag hoe ze Azure DevOps moeten inrichten, beginnen we in de basis met één project. Dit is ook de uitspraak volgens Microsoft:
"Een aanbevolen benadering is om één project te gebruiken ter ondersteuning van uw organisatie of onderneming. Eén project kan helpen bij het minimaliseren van het onderhoud van beheertaken en biedt ondersteuning voor de meest geoptimaliseerde en volledige flexibiliteit voor objectoverschrijdende koppelingen."
Vervolgens stellen we een aantal vragen aan de klant. Indien een vraag met een ja beantwoord wordt, is dit een grote indicatie dat er niet vanuit één project gewerkt kan worden:
- Is er sprake van het mogelijk afstoten van bepaalde dienstverlening en/of applicaties of dient code qua ownership overgedragen te worden aan een derde partij? Zo ja, pleit dit zelfs voor een separate Azure DevOps organisatie per mogelijke ownership. Zodoende zijn de kosten van migraties laag.
- Is er sprake van samenwerking met derden waardoor externe accounts toegevoegd dienen te worden? Indien het antwoord ja is, pleit dit voor een apart project per externe partij omdat we niet willen zien dat de externe partijen elkaar kunnen zien.
- Is er sprake van verschillende werkwijzen over de teams? Gebruikt het ene team bijvoorbeeld de scrum methodiek en de andere kanban? Zo ja, dan pleit dit voor verschillende projecten. Per project kan er een proces template aangewezen worden. De werkwijze van de teams dienen dus redelijk in de buurt te liggen indien ze binnen één project werken.
- Is er sprake van meerdere business units binnen de organisatie elk met hun eigen verantwoordelijkheid? Zijn daarnaast zaken zoals auditing, ISO-certificering, e.d. belangrijk? Zo ja, dan pleit dit voor dat elk business unit hun eigen project krijgt binnen Azure DevOps. Belangrijk is om te begrijpen dat dit Conways law De applicatie structuren volgen nog meer de organisatiestructuren als ook ontwikkelplatformen zo zijn ingericht. Speciale aandacht is vereist voor cross-unit samenwerkingsverbanden en innersourcing.
- Is er sprake van scaled agile of rapportage wensen over de business units heen? Zo ja, pleit dit voor een apart project ten behoeve van portfolio management.
Uit deze vragen hebben we een aantal organisata’s (persona’s maar dan voor organisaties) opgesteld.
Global Investments Inc.
Global Investments inc. is een organisatie die bedrijven opkoopt en afstoot. Ze hebben diverse sectoren waarin ze operationeel zijn. Elk sector heeft wel een aantal applicaties die continu in ontwikkeling zijn.
In deze situatie adviseren wij aparte Azure DevOps organisaties aan te maken voor de verschillende bedrijfsonderdelen. De Azure DevOps organisaties zijn in hun geheel over te dragen naar andere partijen door de ownership te veranderen en deze te koppelen aan een andere Microsoft Entra ID.
Houthakkerij de Spaanplaat
Houthakkerij de spaanplaat heeft vier ontwikkelteams en onderhouden in totaal tien applicaties waarbij soms applicaties door team A wordt aangepast en een andere keer door team B. De vier ontwikkelteams ontwikkelen alle vier doormiddel van de scrum methodiek.
In dit geval kiezen we voor één project binnen Azure DevOps. De argumentatie is:
- Alles is open binnen het project. Niets hoeft afgeschermd te worden tussen de ontwikkelaars.
- De werkwijze van de teams zijn nagenoeg hetzelfde
- Er is co-ownership op het gebiedt van de code. Hoewel één team eindverantwoordelijk blijft voor de code van een applicatie kunnen andere teams mee-ontwikkelen (innersourcing)
Delta-N (wijzelf)
Delta-N ontwikkeld software voor klanten. Soms ontwikkelen we één applicatie voor de klant, soms meerdere. Binnen Azure DevOps creëren wij per klant een project. De redenen waarom wij voor elke klant een project aanmaken zijn:
- Soms wil de klant meekijken in de code of meewerken in Azure Boards. Hierbij is het natuurlijk uit den boze als de klant namen ziet van andere klanten. Het externe klantaccount wordt alleen toegevoegd aan het desbetreffende klantproject
- Er kunnen meerdere projecten of applicaties worden aangemaakt per klant. Hier zetten wij teams in binnen het project in binnen Azure DevOps
Ook hebben wij als Delta-N een aantal separate omgevingen, bijvoorbeeld voor het testen van preview features zodat onze productie omgeving niet geraakt worden en ook voor het geven van webinars en demo’s hebben we aparte omgevingen zodat het niet zichtbaar is voor welke klanten we werken aan de buitenwereld.
De Groene Bank
De groene bank is een nieuwe bank die gaat voor 100% groen. Ze hebben duizend medewerkers en maar liefst driehonderd IT-ers. Naast betaalrekeningen verstrekken ze ook hypotheken en verzekeringen. In de toekomst willen ze ook private banking gaan ondersteunen voor klanten die meer dan 1 miljoen aan geld hebben in hun portefeuille. Er wordt volledig DevOps gewerkt en de ontwikkelteams hebben eigen regie.
In deze situatie kiezen we ervoor dat elk business unit – die uiteraard een representatie zijn van de dienstverlening - zijn eigen project krijgt.
- De IT-systemen worden ontwikkeld specifiek voor elke business unit. Een ontwikkelaar van een hypotheeksysteem heeft in de basis niets te maken met de code van het betaal- en spaarsysteem. Ook innersourcing met betrekking tot dit soort systemen komt meestal niet voor.
- Auditing en ISO-certificeringen kunnen ook eisen dat code niet zomaar door iedereen binnen de organisatie ingekeken kan worden.
- Centrale applicaties of code ten behoeve van het platform kan wel worden geplaatst in een project die voor iedereen toegankelijk is.
De Schaalbare Bank
De schaalbare bank lijkt op de groene bank maar is de oudste bank van het land en kent een betrouwbaar en stabiel klantenbestand. Ze hebben tweeduizend medewerkers en maar liefst zeshonderd IT-ers. Ze doen alles, van hypotheken, sparen, private banking en zijn beursgenoteerd. De organisatie probeert agile te werken en heeft SAFe omarmt. Portfolio management speelt een grote rol binnen de organisatie. Rapportages over de voorgang van epics en features dienen dagelijks te worden gecreëerd.
Ook hier kiezen we voor één project per business unit met dezelfde argumentatie als bij de groene bank. Daarnaast creëren we een speciaal project waar iedereen in kan werken namelijk het portfolio managementproject. In dit project beheren we de Azure Boards Delivery plans en worden de epics- en feature planningen bijgehouden. De business units werken in hun eigen project met user stories.
Door één centraal project aan te maken voor portfolio management is het overzichtelijk wat er gebeurd binnen de organisatie.
De dont’s met Azure DevOps en de project inrichting
Als laatste hebben we nog een aantal tips wat je absoluut niet moet doen indien je werkt met Azure DevOps en de project inrichting:
- Voor elk systeem of applicatie een project aanmaken. Dit zorgt voor extra administratie op het gebied van rechten, gebruikersbeheer en resources kunnen lastig gedeeld worden over de verschillende projecten
- Voor elk team een project aanmaken. Dit zorgt ervoor dat code minder makkelijk gedeeld kan worden en het blokkeert innersourcing.
Kies een juist model
Azure DevOps is een veelzijdig product en je dient als organisatie een juist model te kiezen. Wat het juiste model is hangt geheel af van de organisatie zelf.
Om het maar op zijn NLP’s te zeggen: Elke keuze die je maakt qua inrichting is de beste keuze op basis van de inzichten en kennis die je op dat moment hebt.
Wil jij hulp bij het kiezen van een juist model? Neem dan contact met ons op.
