Így gyorsítja fel a GitHub a felhőbevezetést

Cikk
07/28/2023

Áttekintés

Az innováció a mai versenyhelyzet új pénzneme. A megosztás, a tartalmak streamelése, az önvezető autók és más szolgáltatások alapjaiban változtatták meg az emberek napi ritmusát, miközben a piacokat fejjel lefelé fordítják, és bemutatják, hogyan változott a versenyhelyzet a fizikai eszközökről a digitális élményekre.

Ezek a kivételes digitális élmények forradalmasítják a piacot, és a jól ismert vállalkozások számára ma már komoly konkurenciát jelentenek az innovatívabb cégek, amelyek gyorsabban tudnak értéket közvetíteni az ügyfeleiknek. A versenyképesség fenntartása és a nehézségek elkerülése érdekében a vállalkozásoknak be kell vezetniük az innováció kultúráját, valamint a legjobb és legmegfelelőbb eszközöket és felhőszolgáltatásokat kell alkalmazniuk.

A GitHub által biztosított szolgáltatások az alábbiakban segíthetik a vállalatokat:

az Azure szolgáltatásainak és képességeinek igénybevételében;
a vállalat gyakorlatának modernizálásában;
valamint abban, hogy rugalmasan és innovatívan tudják végrehajtani ezt a kulturális átállást.

A vállalatok kihasználhatják a GitHub nyílt forráskódú közösséghez való kapcsolódásának előnyeit, és több ezer megismételt, továbbfejlesztett és üzembe helyezhető felhőmegoldás-példát találhatnak olyan szervezetektől, amelyek sikeresen bevezették az Azure-szolgáltatásokat. Könnyedén kölcsönözhetnek ezekből a megoldásokból, és iterációkkal az üzleti szükségleteikhez igazíthatják őket.

A GitHub megkönnyíti a szervezetek számára a csapatok közötti megosztást, ami felgyorsítja a modernizációt, illetve további alkalmazások és tevékenységprofilok üzembe helyezését. A vállalatok az InnerSource-t, az innováció kulcsfontosságú alapkontrasztját tekinthetik át, hogy olyan ajánlott eljárásokat vehessenek fel, mint a megosztás és az újrahasználat, az együttműködés és a kommunikáció, és még sok más a nyílt forráskódú közösségtől, és alkalmazzák őket a szervezeten belül.

A teljes szoftveres ellátólánc biztosítását – a nyílt forráskódú csomagoktól a napi szinten írt szellemi tulajdonig – minden cégnek kiemelt fontosságú feladatként kellene kezelnie. Ehhez a célhoz fejlett biztonsági technológia szükséges, amely a teljes életciklus során beépíthető és automatizálható, és az olyan natív GitHub-képességek, mint a GitHub fejlett biztonsága és a GitHub Actions, ezt a típusú rugalmasságot kínálják.

A nyílt forráskódú objektumok igénybevétele

A rendkívül hatékony szervezetek felismerik, hogy a nyílt forráskódú szoftverek (OSS) használata elengedhetetlen a modern szoftverfejlesztéshez. Kapcsolatban állnak azokkal a fejlesztő közösségekkel, amelyektől függnek, és egy biztonságos platformot használnak az OSS-be való megfontolt befektetésekhez. Ezek a cégek ezért gyorsan képesek újítani, maguk mögött hagyják a konkurenciát, és csökkentik a költségeket, miközben minimalizálják a kockázatot.

Míg az OSS-t értelmezhetjük alkalmazásokba ültetett csomagokként, kódtárakként, szkriptekként és függőségekként is, több ezer nyílt forráskódú objektum érhető el infrastrukturális kód (IaC), dokumentáció, útmutató és terv formájában a jól definiált Azure-architektúrák létrehozásához. Ezeket a terveket a Microsoft, partnerek, forgalmazók, ügyfelek és magánszemélyek ajánlották fel az OSS-közösségnek, és elérhetők a GitHubon. Ezek egyszerűen módosíthatók, újra felhasználhatók és üzembe helyezhetők egy adott Azure-környezetben.

Infrastruktúra mint kód

Az infrastruktúra kódként (IaC) való használata az infrastruktúra felügyelete (a hálózatoké, virtuális gépeké, terheléselosztóké és a kapcsolati topológiáé) egy leíró modellben, amely megegyezik a DevOps csapat által a forráskódhoz használt verziószámozási rendszerrel. Ahhoz az alapelvhez hasonlóan, hogy egy adott forráskód mindig ugyanazt a bináris kódot állítja elő, az infrastruktúra kódként való használatára épülő (IaC) modellek is minden egyes alkalmazáskor ugyanazt a környezetet hozzák létre. Az IaC egy kulcsfontosságú DevOps-gyakorlat, amelyet a folyamatos teljesítéssel (CD) együtt használnak.

Azért fejlesztették ki, hogy megoldja a környezeti eltérés problémáját a kiadási folyamatban. Az IaC nélkül az informatikai csapatoknak felügyelniük kell az egyes üzembehelyezési környezetek beállításait, az egyes környezetek közötti eltérések pedig problémákat okozhatnak az üzembe helyezés során. Idővel minden környezet olyan lesz, mint egy hópehely: egy egyedi konfiguráció, amely automatikusan nem reprodukálható. A hópehelyekkel az infrastruktúra felügyelete és karbantartása manuális folyamatokat igényel, amelyek hozzájárulnak a hibákhoz, és nehezen követhetők. Az IaC-vel rendelkező infrastruktúra-telepítések megismételhetők, és megakadályozzák a konfigurációs eltérés vagy a hiányzó függőségek által okozott futásidejű problémákat.

Az IaC-vel a csapatok módosíthatják a környezet leírását és a konfigurációs modell verziószámozását, amely jellemzően jól dokumentált kódformátumokban, például JSON-ban van megadva; további információ: Azure Resource Manager-sablonok. A fejlesztők egyszerűsíthetik a munkafolyamataikat, ha az IaC-kódot ugyanabban a GitHub-adattárban üzemeltetik, mint az alkalmazás forráskódját, és ugyanazokat a folyamatos integrációs (CI) /CD-eljárásokat vezetik be a GitHub Actions által működtetett IaC-hez.

Tekintse meg az AzOps GitHub-műveletet, amely bemutatja, hogyan helyezhet üzembe egyéni Resource Manager-sablonokat különböző Azure-hatókörökben. Ha még nem ismeri a Resource Manager-sablonokat vagy az IaC-t, a GitHubon is tallózhat az azure-quickstart-templates adattárban , megkeresheti az üzembe helyezni kívánt sablont, és az Üzembe helyezés az Azure-ban gombra kattintva tesztelheti annak működését.

Screenshot of a Deploy to Azure button.

Felhőminta-összetevők és ajánlott eljárások

Az alábbi architektúradiagram a GitHub DevSecOps-környezet GitHub- és Azure-összetevőiben futó biztonsági ellenőrzéseket emeli ki:

An architecture diagram highlighting the security checks that run in the GitHub and Azure components of a GitHub DevSecOps environment.

A GitHub egy kód-üzemeltetési platformot biztosít, amelyet a fejlesztők használhatnak nyílt forráskódú és InnerSource-projekteken való együttműködéshez.
A Codespaces egy online fejlesztői környezet. A Microsoft Visual Studio Code-ra épülő és a GitHubon üzemeltetett eszköz teljes körű, felhőalapú fejlesztési megoldást kínál.
A GitHub biztonsága több módon is kiküszöböli a fenyegetéseket. Az ügynökök és a szolgáltatások azonosítják a biztonsági réseket az adattárakban és a függő csomagokban. Emellett a függőségeket is frissítik az aktuális és biztonságos verziókra.
A GitHub Actions olyan egyéni munkafolyamatokat tartalmaz, amelyek közvetlenül az adattárakban biztosítják a CI/CD-képességeket. Ezeket a CI/CD-feladatokat futtatóknak nevezett számítógépek üzemeltetik.
A Microsoft Entra ID egy több-bérlős, felhőalapú identitásszolgáltatás, amely szabályozza az Azure-hoz és más felhőalkalmazásokhoz, például a Microsoft 365-höz és a GitHubhoz való hozzáférést.
Az Azure App Service a webalkalmazások létrehozásához, üzembe helyezéséhez és skálázásához nyújt keretrendszert. Ez a platform beépített infrastruktúra-karbantartást, biztonsági javítást és skálázást kínál.
Az Azure Policy segítségével a csapatok felhőalapú erőforrásokra vonatkozó szabályokat kikényszerítő szabályzatdefiníciókkal kezelhetik és előzhetik meg az informatikai problémákat. Ha például egy projekt egy ismeretlen termékváltozatú virtuális gép üzembe helyezésére készül, az Azure Policy riasztásokat küld a problémáról, és leállítja az üzembe helyezést.
Felhőhöz készült Microsoft Defender egységes biztonságkezelést és fejlett fenyegetésvédelmet biztosít a hibrid felhőbeli számítási feladatokhoz.
Az Azure Monitor teljesítménymetrikákat, tevékenységnaplókat és egyéb alkalmazástelemetria-adatokat gyűjt és elemez. Ez a szolgáltatás riasztást küld az alkalmazásoknak és a személyzetnek, ha szabálytalan feltételeket azonosít.

InnerSource

InnerSource – áttekintés

Számos vállalat az InnerSource kifejezést használja a mérnöki csapataik közös kódolási munkavégzésének leírására. A InnerSource olyan fejlesztési módszer, amelynek keretében a mérnökök saját fejlesztésű szoftvereket készítenek a nagy léptékű nyílt forráskódú projektek, például a Kubernetes vagy a Visual Studio Code bevált eljárásainak felhasználásával.

A nagy léptékű, nyílt forráskódú projektek több ezer közreműködőtől igényelnek koordinációt és csapatmunkát. A legsikeresebb projekteket a jövőbeli és napi felhasználói igényekre vonatkozó jövőkép vezérli: a sebesség, a megbízhatóság és a funkcionalitás. Az a skálázás, amelyen ezek a projektek működnek, tanulságokat biztosít, és segíthet a vállalatoknak a jobb szoftverek gyorsabb kiépítésében az InnerSource-nal.

A GitHub lekéréses kéréseivel és problémáival az együttműködés és a kód áttekintése beépül a fejlesztési folyamatba. A belső és a kiszervezett csapatok megoszthatják egymással a munkájukat, megvitathatják a módosításokat és visszajelzéseket kaphatnak – mindezt egy helyen. Ez segít a szervezeteknek belsőleg megosztani a szakértelmet, valamint elkerülni, hogy újból ki kelljen dolgozniuk az olyan, más projektekhez korábban kifejlesztett megoldásokat, amelyeket már élesben teszteltek.

Az InnerSource-projektek anatómiája

Az egyének, a csapatok és az erőforrások megfelelő együttese biztosíthatja a projekt sikerességét. Számos nyílt forráskódú projekt hasonló szervezeti struktúrát követ, amely segíthet a szervezeteknek, hogy keresztfunkcionális csapatokat hozzanak létre az InnerSource-projektek kezeléséhez. A nyílt forráskódú projektekben jellemzően a következő típusú személyek vesznek részt:

Karbantartók: Ezek a közreműködők felelősek a projekt jövőképének irányításáért és a projekt szervezeti aspektusainak irányításáért. Nem minden esetben ők a kód eredeti tulajdonosai vagy létrehozói.
Közreműködők: Ezek az emberek mindenki, aki hozzájárult a projekthez.
Közösségi tagok: Ők azok, akik a projektet használják. Lehet, hogy aktívak a beszélgetésekben, vagy véleményt nyilvánítanak a projekt irányáról.

A nagyobb projektek albizottságokkal vagy munkacsoportokkal is rendelkezhetnek, amelyek különböző feladatokra összpontosítanak, mint például az eszközök, az osztályozás vagy a közösségi moderálás. Az InnerSource-projektek jellemzően hasonló szerkezettel rendelkeznek. Számos mérnöki szervezet alakít ki csapatokat a különböző területek, például az alkalmazástervezés, a platformtervezés vagy a webes fejlesztés szerint. A szervezetek ilyen strukturálása vakfoltokat hagyhat, ami a képzett személyek kihagyásával járhat. Egy szervezeten belüli csapatok által támogatott központi döntéshozó csoport létrehozása segíthet a problémák gyorsabb megoldásához szükséges szaktudás összegyűjtésében.

A vállalaton belül a közreműködők a vállalat fejlesztői, a fenntartók pedig a projekt vezetői és fő döntéshozói.

Karbantartók: Fejlesztők, termékmenedzserek és más kulcsfontosságú döntéshozók egy vállalaton belül, amely felelős a projekt elképzeléseinek megvalósításáért és a napi hozzájárulások kezeléséért.
Közreműködők: Fejlesztők, adattudósok, termékmenedzserek, marketingesek és más szerepkörök a vállalaton belül, amelyek elősegítik a szoftverek továbbterjesztését. Előfordulhat, hogy a közreműködők nem részei a projekten közvetlenül dolgozó csapatnak, de programkód létrehozásával, hibajavítások elküldésével és egyéb megoldásokkal segítenek a szoftverek fejlesztésében.

További információ: Az InnerSource bemutatása című tanulmány.

Automation

A GitHub Actions lehetővé teszi, hogy a felhasználók egyéni munkafolyamatokat hozzanak létre közvetlenül a GitHub-adattáraikban. A felhasználók felderíthetik, létrehozhatják és megoszthatják a műveleteket egy adott feladat végrehajtásához, beleértve a CI/CD-t, és egy teljesen személyre szabott munkafolyamatban kapcsolhatják össze a műveleteket. Emellett olyan CI-munkafolyamatokat is létrehozhatnak, amelyek különböző programozási nyelveken írt projektek összeállítására és tesztelésére szolgálnak. Példák a GitHub Actions útmutatóiban találhatók.

A GitHub Actions segítségével összekapcsolhatók az IaC-alapelvek és a CI/CD-gyakorlatok a teljes üzembehelyezési életciklus automatizálása céljából, beleértve a célkörnyezet megismételhető módon történő kiépítését vagy frissítését, valamint az alkalmazás csomagolását és üzembe helyezését.

Példa

Az Azure-hoz készült GitHub Actions egyszerűbbé teszi az olyan Azure-szolgáltatásokkal kapcsolatos üzembehelyezési folyamatok automatizálását, mint például az Azure App Service, az Azure Kubernetes Service, az Azure Functions és hasonlók. Az Alapvető műveleteket alkalmazó Azure-munkafolyamatok adattára teljes körű munkafolyamatokat tartalmaz, amelyekkel bármilyen nyelven és környezetben létrehozhat webalkalmazásokat, és üzembe helyezheti őket az Azure-ban. Látogasson el a GitHub piacterére az összes elérhető művelet megtekintéséhez.

Biztonság

A GitHub balról balra irányú biztonsági funkciói

A DevSecOps a fejlesztés legelső lépéseitől kezdve követi a biztonsággal kapcsolatos ajánlott eljárásokat. A shift-left megközelítésen alapuló stratégia alkalmazásával a DevSecOps máshová helyezi a hangsúlyt a biztonság szempontjából. A folyamat végén esedékes vizsgálat helyett a kezdeti fejlesztésre összpontosít. Amellett, hogy robusztus kódot eredményez, ez a hibákat gyorsan feltáró fail-fast megközelítés segít a problémák korai megoldásában, amikor még könnyű kijavítani őket.

A számos biztonsági funkcióval ellátott GitHub olyan eszközöket kínál, amelyek a DevSecOps-munkafolyamatok minden területét támogatják:

Böngészőalapú IDE-k, beépített biztonsági bővítményekkel
A biztonsági tanácsadásokat folyamatosan figyelő, valamint a sebezhető és elavult függőségeket lecserélő ügynökök
Olyan keresési képességek, amelyek felderítik a forráskód biztonsági réseit
Műveletalapú munkafolyamatok, amelyek a fejlesztés, a tesztelés és az üzembe helyezés minden lépését automatizálják
Olyan terek, amelyek lehetővé teszik a biztonsági fenyegetések magánjellegű megvitatását és elhárítását, majd az információk közzétételét
Az Azure monitorozási és kiértékelési képességeivel együtt alkalmazva ezek a funkciók kiváló szolgáltatást nyújtanak a biztonságos felhőalapú megoldások létrehozásához