Elke maand brengen we een nieuwe versie van Chrome uit om ervoor te zorgen dat onze miljarden wereldwijde gebruikers en bedrijven de nieuwste functies, beveiligingsupdates en prestatie-upgrades krijgen. En nu kunnen we verbeteringen aanbrengen en problemen sneller dan ooit tevoren oplossen dankzij een snellere releasecyclus, wat betekent dat u nog vaker de nieuwste updates ontvangt.
We spraken met technische programmamanagers Ben Henry, Krishna Govind, Harry Souders, Srinivas Sista en Brandon Heenan van het Chrome-releaseteam voor een kijkje in de manier waarop ze samenwerken met Google-teams over de hele wereld om ervoor te zorgen dat elke release soepel verloopt.
V. Hoe bereidt uw team zich voor op elke Chrome-release?
Ben: Ten eerste bestaat ons team uit zeven mensen die fulltime werken in twee grote regio’s. Wij denken dat de voorbereiding op een release vergelijkbaar is met een treinschema. We gebruiken vier releasekanalen (Canary, Dev, Beta en Stable) om ons voor te bereiden op een Chrome-mijlpaalrelease. Naarmate we het proces doorlopen, heeft elk kanaal meer Chrome-gebruikers. Hierdoor kunnen we feedback krijgen over de stabiliteit en prestaties van Chrome, met als doel kwaliteitsproblemen in het product zo vroeg mogelijk aan het licht te brengen. We letten goed op wat gebruikers en ontwikkelaars zeggen op sociale media, in de persartikelen en in bugrapporten, om te helpen ontdekken wat we nog missen. Ons team van ingenieurs en productmanagers kan deze feedback vervolgens gebruiken om functieverbeteringen aan te brengen.
Vervolgens voeren we verschillende testrondes uit om eventuele kwaliteitsproblemen op te sporen, eerst met behulp van geautomatiseerde systemen die continu draaien, en vervolgens met testteams die bugs handmatig vinden.
V. Kunt u een recent voorbeeld geven van feedback van een externe ontwikkelaar die waardevol was om ervoor te zorgen dat u de best mogelijke versie hebt geleverd?
Srinivas: We vertrouwen altijd op onze webontwikkelaars voor feedback en vroege acceptatie van functies, zoals nieuwe API's of specificatieswijzigingen met Chrome op iOS. Met onze grote mijlpaalverandering van twee cijfers naar drie cijfers (99 naar 100) hebben we richtlijnen gedeeld met webontwikkelaars om dingen uit te testen vóór de daadwerkelijke verandering om ervoor te zorgen dat we hun feedback hebben verwerkt en, nog belangrijker, hun sites niet kapot hebben gemaakt. Dit heeft ons geholpen de wijziging met succes door te voeren zonder grote problemen bij de uitrol van M100.
V. Wat gebeurt er als u tijdens de implementatie van een Chrome-update een bug of beveiligingsprobleem tegenkomt?
Krishna: We zorgen ervoor dat we geleidelijk nieuwe Chrome-releases voor gebruikers uitrollen. Nieuwe releases worden niet onmiddellijk naar 100% van de gebruikers gepusht. Als we een kritieke bug ontdekken, stoppen we de introductie van de getroffen versies om de effecten ervan te beperken. Vervolgens coördineren we met Chrome-teams over de hele wereld om een oplossing te ontwikkelen en Chrome zo snel en veilig mogelijk te patchen. Zodra deze oplossing is geverifieerd, bouwen we een nieuwe versie van Chrome en starten we het uitrolproces opnieuw. Uiteindelijk zullen de meeste gebruikers dit probleem nooit ervaren, omdat het al is opgelost voordat de release ooit naar hen werd uitgerold. Voor beveiligingsproblemen volgen we het Project Zero Disclosure- beleid. Dus als er kwetsbaarheden actief worden uitgebuit, hebben we als doel om die oplossing binnen zeven dagen vrij te geven aan onze stabiele kanaalgebruikers.
V. Moet er extra werk worden verricht om ervoor te zorgen dat Chrome-releases klaar zijn voor bedrijven?
Brandon: Een van onze belangrijkste doelen is ervoor te zorgen dat Chrome een stabiel, betrouwbaar platform blijft voor de vele bedrijven die van ons afhankelijk zijn. Dat betekent dat bedrijven toegang moeten krijgen tot de beste en nieuwste functionaliteit waarvan ze willen dat hun mensen er gebruik van maken, terwijl ze tegelijkertijd worden geholpen potentiële verstoringen van hun werk te voorkomen. Omdat de behoeften van het bedrijfsleven uniek zijn en elke downtime een onderneming kan schaden, heeft Chrome specifieke richtlijnen voor onze technische en productteams en beoordelen we elke nieuwe functie om ervoor te zorgen dat elke Chrome-release 'ondernemingsvriendelijk' is. Dat houdt onder meer in dat we bedrijven op de hoogte stellen van belangrijke wijzigingen in onze Chrome Enterprise Release Notes . En voor extra gemoedsrust kunnen IT-beheerders veel wijzigingen beheren met een ondernemingsbeleid . Dus als ze liever interne tests uitvoeren of zich afmelden voor een nieuwe functie, kunnen ze dat doen. Om onverwachte problemen te voorkomen, hebben we een speciale testinfrastructuur die is ontworpen om bedrijfsomgevingen te simuleren (bijvoorbeeld Chrome draaien op apparaten die aan het Active Directory-domein zijn gekoppeld) die we gebruiken om alle Chrome-releases te testen.
Chrome biedt ook een reeks updateopties voor scholen en bedrijven. Beheerders kunnen de specifieke versie van Chrome beheren, teruggaan naar oudere versies en profiteren van ons volledig ondersteunde uitgebreide stabiele releasekanaal. De details leest u in dit technische document . Beheerders die volledig inzicht willen in de updatestatus van hun wagenpark, kunnen het versierapport gebruiken dat is opgenomen in Chrome Browser Cloud Management .
V. Zijn er veranderingen die uw team in de toekomst wil doorvoeren?
Harry: We zijn altijd op zoek naar manieren om Chrome te verbeteren voor onze gebruikers en ontwikkelaars, vooral als het gaat om het verkorten van de releasecyclus. Door dit te doen, zullen gebruikers een stabieler Chrome zien met snellere bugfixes en nieuwe functies. We weten ook dat onze technici en productmanagers profiteren van een hogere ontwikkelingssnelheid als gevolg van snellere ontwikkeling van functies, snellere iteratiecycli en een betere codestatus. Stel dat een productmanager een functie voor alle Chrome-gebruikers wil lanceren. Het kan tot 16 weken duren vanaf het moment dat de functie 'klaar' is tot het moment waarop deze algemeen beschikbaar is. Door de releasecyclus met slechts een paar weken te verkorten, kunnen we de doorlooptijd voor het lanceren van een nieuwe functie aanzienlijk verkorten.