Magento-developers toegang geven

Een previewomgeving past bij een specifieke branch, fix of supportonderzoek. Staging is meestal een langer beschikbare omgeving om releases op de productiestack te testen. In een acceptatieomgeving bevestigt de merchant of het deliveryteam het bedrijfsproces. Teams gebruiken deze namen verschillend. Belangrijker is welke code, services, data en integraties de omgeving bevat en wie die mag veranderen.

Bereid voor modulesupport de Magento-release, relevante extensies, PHP en ondersteunende services voor waarmee het probleem kan worden gereproduceerd. Gebruik een branch voor de voorgestelde fix, zodat de leverancier kan onderzoeken zonder ander werk op gedeelde staging te verstoren. Adobe adviseert eerst op staging te testen voordat productie wordt aangepast. Een representatieve omgeving maakt die beoordeling zinvol.

Een aparte hostname maakt op zichzelf nog geen veilige testomgeving. Controleer database, betaalconfiguratie, e-mail, webhooks en achtergrondintegraties vóór de overdracht. De developer moet het probleem kunnen uitlokken zonder een echte betaling te doen, een klantmail te versturen of orders in een live extern systeem te veranderen.

Vraag iedere developer om de publieke SSH-key en voeg deze aan de geselecteerde site toe. De private key blijft bij de developer. Geef het record een herkenbaar label, bijvoorbeeld leverancier, developer en supportticket. Je team kan dan later vaststellen bij wie de toegang hoort. Een gedeeld wachtwoord of een gezamenlijke leverancierskey maakt die overdracht en verwijdering moeilijker te beheren.

Bij Intercube brengt de SSH-keyworkspace van de site de publieke key, het label en de vervaldatum bij elkaar. Stel de einddatum in wanneer je toegang geeft en stem deze af op de supporttaak. Statussen voor actieve, binnenkort vervallende en verlopen keys geven je team overzicht van het toegangsvenster. Zo blijft een leveranciersverzoek makkelijk terug te vinden en te beoordelen.

Geef de developer voor een onderzoek van twee dagen een herkenbare key met die afgesproken einddatum. Is het werk eerder klaar, verwijder dan de key van de site. Is meer tijd nodig, keur dan een nieuwe datum goed. Je team houdt controle over het toegangsvenster terwijl de leverancier de omgeving krijgt om het probleem op te lossen.

Een productiekopie kan klantgegevens, orderhistorie, API-credentials en configuratie voor gekoppelde systemen bevatten. Beoordeel die kopie voordat zij een hulpmiddel voor de developer wordt. Verwijder onnodige persoonsgegevens en productiecredentials en spreek af wat de leverancier mag bekijken of exporteren. Gebruik testorders of een kleinere dataset wanneer die het probleem reproduceert.

Gebruik afzonderlijke credentials en endpoints voor de testomgeving. Zet betaalproviders in testmodus, vang uitgaande e-mail op of beperk die en gebruik testendpoints voor ERP-, fulfilment- en marketingintegraties. Schakel koppelingen uit wanneer ze geen onderdeel van het onderzoek zijn. Controleer cron en queue consumers naast de storefront. Achtergrondtaken kunnen een live systeem aanspreken terwijl de pagina eruitziet als staging.

Spreek vóór de toegang af welke beheerrechten en bestanden nodig zijn. Via SSH kunnen applicatieconfiguratie en andere bestanden leesbaar zijn voor de sitegebruiker. Intercube-engineers bereiden runtime en services met je team voor; de merchant en het applicatieteam keuren de dataset en bedrijfsintegraties voor het onderzoek goed.

Laat de leverancier een modulerelease, patch of beoordeelde codewijziging aanleveren, met reproductiestappen en tests die de oplossing aantonen. Bewaar die in de repository zodat je ontwikkelaars het verschil kunnen onderzoeken en opnieuw bouwen. Een handmatige wijziging op de testserver kan nuttig zijn tijdens de diagnose, maar hoort niet de enige kopie van de oplossing te blijven.

Test de fix via preview en de relevante acceptatiecontroles en breng deze vervolgens via de productiepipeline uit. Deploymentpipelines zijn inbegrepen in het Intercube-hostingplan, met buildstappen, logs en releasehistorie. Je team kan die route gebruiken zonder voor deze hostingomgeving een aparte deploymentworkflow in GitHub Actions samen te stellen.

Valideer checkout, betalingen, klantaccounts, geplande taken en integraties die de module raakt. Spreek databasewijzigingen en een eventueel onderhoudsvenster vóór de productiedeployment af. Een geslaagde leverancierstest draagt bij aan releasegoedkeuring. Je team bepaalt nog steeds of de volledige shop gereed is.

Toegang verwijderen hoort bij de afronding van het supportticket. Verwijder de site-SSH-key, laat de beheerde configuratiewijziging afronden en controleer dat de key geen nieuwe verbinding meer toestaat. Beoordeel een tijdelijk beheeraccount, repository-uitnodiging, API-token en databasecredential afzonderlijk. Eén SSH-key verwijderen trekt die andere toegangswegen niet in.

Leg de uiteindelijke patch, releasegoedkeuring en afgesloten toegang vast in het ticket. Beëindig de onderzoekssessie en beoordeel processen of tijdelijke integraties die voor het werk zijn aangemaakt. Verwijder de previewomgeving na het onderzoek of geef haar een nieuw doel en eigenaar wanneer het team haar wil behouden.

Heeft de leverancier nog toegang nodig, geef de verlenging dan een nieuwe beoordeling en einddatum. Een previewomgeving, herkenbare key en bewuste afsluiting laten developers het probleem oplossen zonder dat één supportvraag permanente toegang tot de shop oplevert.