Pseudo ontwikkelomgeving

Overzicht

Een Ansible-ontwikkelomgeving, of eenvoudigweg ontwikkelomgeving, is de geconfigureerde opzet waar ontwikkelaars Ansible-playbooks, Ansible-rollen, inventarissen en gerelateerde automatiseringsartefacten creëren, testen en beheren. Het draait om een primaire ontwikkel-desktop, die dient als het hoofdwerkstation voor deze taken. Deze omgeving omvat typisch essentiële tools zoals Ansible Core, virtuele omgevingen (bijv. met Vagrant, LXD, VirtualBox, Docker) voor geïsoleerd testen, versiebeheersystemen zoals Git en optionele componenten zoals IDE-plugins.

In de standaard open-source C2 Platform-benadering vormt de ontwikkel-desktop de gehele omgeving en biedt volledige flexibiliteit voor lokale ontwikkeling. Daarentegen gebruiken klantomgevingen vaak een virtuele machine als ontwikkel-desktop, gecombineerd met provisioned nodes die worden beheerd via tools zoals vRealize Automation (vRA).

Pseudo ontwikkelomgeving

Een pseudo ontwikkelomgeving is een suboptimale variant van de standaard ontwikkelomgeving. Deze komt vaak voor in beperkte klantomgevingen, zoals Nederlandse overheidscontexten, waar beveiliging, beperkingen in resources of organisatorische beleidsregels de volledige flexibiliteit beperken. In tegenstelling tot de ideale open-source opzet, prioriteert een pseudo ontwikkelomgeving gedeelde resources en gecontroleerde toegang boven de autonomie van individuele engineers.

Belangrijke kenmerken zijn:

• Gedeelde resources: De omgeving wordt vaak gedeeld door meerdere engineers. Hoewel elk een aparte desktop kan hebben, zijn de doel-testnodes gemeenschappelijk. Dit vereist coördinatie van taken binnen en soms tussen teams om conflicten tijdens testen of ontwikkeling te vermijden.

• Beperkt VM- en snapshotbeheer: Het creëren van virtuele machines (VM’s) en snapshots is sterk beperkt en niet geautomatiseerd, vaak met handmatige goedkeuringsprocessen. In een echte ontwikkelomgeving kunnen engineers zoveel VM’s en omgevingen provisioneren als nodig met volledige flexibiliteit, geautomatiseerd via Vagrant-providers zoals LXD of VirtualBox.

• Prestatievertragingen: Operaties zoals het creëren, resetten van VM’s of herstellen van snapshots duren aanzienlijk langer vanwege afhankelijkheid van gedeelde infrastructuur in plaats van lokale SSD’s in een geoptimaliseerde lokale opzet. Dit kan iteratie- en testcycli vertragen.

• Beperkingen in automatisering: Het automatiseren van VM- en snapshotcreatie is beperkt door factoren zoals netwerkscheiding, gebrek aan API-toegang of beveiligingsbeleid. Dit belemmert snelle prototyping en experimentatie, die kenmerkend zijn voor een effectieve Ansible engineering-workflow.

Vergelijking met standaard ontwikkelomgeving

De standaard ontwikkelomgeving benadrukt de empowerment van engineers, automatisering en snelheid, in lijn met open-source best practices. Het stelt Ansible engineers in staat om desired state configurations volledig te testen in geïsoleerde, reproduceerbare opzetten. Daarentegen ruilt de pseudo ontwikkelomgeving deze voordelen in voor compliance en resource-efficiëntie in enterprise-omgevingen. Hoewel het samenwerking mogelijk maakt, kan het knelpunten introduceren die de productiviteit sterk verminderen. Uit ervaring leidt dit vaak tot mislukte deadlines en sprintdoelen. Een pseudo ontwikkelomgeving lijkt aanvankelijk goed te werken, maar zodra uitdagendere Ansible engineering en testen betrokken raken, verslechtert de situatie snel.

Bijvoorbeeld, in een standaard opzet zou een engineer een lokale Vagrantfile in een Ansible-inventarisproject kunnen gebruiken om testnodes onmiddellijk op te starten. In een pseudo omgeving zou dezelfde actie een verzoek aan een centraal IT-team kunnen vereisen, met wachttijden van uren of dagen voor provisioning. Sommige moeilijke automatiseringsproblemen vereisen zeer frequente tests vanaf een baseline, tot 15 of 20 keer per dag, wat onpraktisch wordt in zulke beperkte opzetten.

Beste praktijken

De meest effectieve best practice is om het kernconcept van het C2 Platform te adopteren van Open, tenzij: Een open aanpak vergemakkelijkt het hergebruik van ideeën en code, niet alleen binnen projecten, maar zelfs tussen verschillende organisaties. —prioriteren van open-source benaderingen tenzij specifieke beperkingen anders vereisen. Nederlandse overheidsorganisaties kunnen bijvoorbeeld Ansible engineering verplaatsen naar het open-source C2 Platform. Dit elimineert de noodzaak voor elke organisatie om eigen closed-source rollen te ontwikkelen voor gemeenschappelijke componenten zoals Apache, Tomcat of custom Ansible-modules (bijv. voor Microsoft Software Center). Het delen van deze resources openlijk bevordert samenwerking, vermindert redundantie en versnelt innovatie.

Deze benadering creëert ook een robuuste leeromgeving en stelt engineers in staat om vanaf dag één productief te zijn. Daarentegen vertragen pseudo ontwikkelomgevingen in klantomgevingen vaak de onboarding vanwege vereisten voor accounts, permissies en beveiligingsgoedkeuringen, die maanden kunnen duren. Een open-source opzet omzeilt deze barrières en maakt onmiddellijke bijdragen mogelijk.

Aanvullende mitigerende maatregelen zijn:

• Pleiten voor beleidsaanpassingen om meer automatisering toe te staan, zoals beperkte API-toegang voor VM-beheer.
• Documenteren van richtlijnen voor het gebruik van gedeelde resources om conflicten te minimaliseren.

Door deze verschillen te begrijpen, kunnen teams hun Ansible operations en engineering-praktijken aanpassen om effectief te werken binnen beperkte omgevingen, terwijl ze streven naar meer ideale opzetten.