GitHub kampt met downtime door opslagproblemen

GitHub heeft maandagochtend te maken met storingen door problemen met een opslagsysteem. De problemen begonnen zondagavond maar duren voort, ook na de migratie van opslagsystemen om de toegang tot GitHub.com te herstellen.

GitHub.com kampte zondagavond met downtime, waarna de oorzaak werd gevonden bij problemen met een opslagsysteem. De uren daarna probeerde GitHub het opslagsysteem te migreren en het systeem te herstellen, blijkt uit meldingen op de statuspagina van de dienst. In de ochtend maakte de dienst bekend dat het herstel naar verwachting binnen enkele uren gereed is.

De problemen hadden tot gevolg dat ontwikkelaars wereldwijd moeite hadden de site te benaderen. Ook lijkt het erop dat de dienst tijdelijk een oudere back-up draaide want onder andere op Twitter melden ontwikkelaars dat ze verouderde bestanden geserveerd krijgen en pushes niet doorkwamen.

In juni maakte Microsoft bekend GitHub over te willen nemen, voor 7,5 miljard dollar.

Reacties (101)

[Zeror]

Toch vervelend als je afhankelijk bent van Github en daardoor je werk niet kunt doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

[12_0_13]

Git is decentraal, dus als Github even down is kan je gewoon pushen / pullen naar/van elkaars werkplek. En daarna weer pushen naar GitHub.
Het is *juist* handig om dingen die anderen beter kunnen (hosting, uptime, patching, sizing etc). uit te besteden zodat je meer tijd hebt voor daadwerkelijk ontwikkelwerk. Zeker in deze tijden waar ontwikkelaarstijd erg schaars is.

[Reactie gewijzigd door 12_0_13 op 22 juli 2024 23:40]

[timvisee]

Het probleem is dat GitHub het decentrale Git centraliseerd. Er zijn flink veel tools, package managers, issue management, CI straten, noem maar op, die afhankelijk zijn van GitHub.

[Wraldpyk]

Klopt, maar je hebt hier te maken met een kortstondige downtime van maximaal een aantal uren. Daardoor ben je echt niet afhankelijk van GitHub en zoals @12_0_13 zei kun je prima van/naar elkaar machine pushen. Zodra GitHub dan weer draait is alles weer ok.

[jesse!]

GitHub is momenteel al 19 uren niet volledig operationeel.
Wat vind jij "een aantal uren"?

01:09 CEST kwam eerste status update. En tot nu toe (20:20) werkt GitHub nog steeds niet volledig.

[j1b2c3]

Het is vervelend , Maar Op jaar basis is dat een downtime 0,2% dus niets schokkends

[jesse!]

Dat kan dus een hele dag offline betekenen.

Natuurlijk kan je dan zeggen dat je er minder afhankelijk van moet zijn. Maar voor kleinere bedrijven is dat niet altijd mogelijk.
Ook omdat veel mensen gewoon betalen voor de dienst.

[SunnieNL]

Als je er afhankelijk van bent neem je dat risico dus als bedrijf.
Als je dat risico niet wil lopen moet je een andere SLA afsluiten (wat blijkbaar niet kan) of een andere oplossing zoeken of tools die niet afhankelijk zijn van github zelf

[defixje]

Je kan altijd heel makkelijk zelf een git repo servertje plaatsen, kost maximaal 500,-.

Desnoods wijs je een PC aan die een repo draait (mochten de financiele middelen er niet voor zijn)

[jesse!]

Dan heb je weer iemand nodig die daar de kennis van heeft.
GitHub maakt Git eenvoudig, en er zijn genoeg tools die eenvoudig bij elkaar te klikken zijn voor je deploy.
Zodat je niet al te technische mensen nodig hebt.

[defixje]

True, maar dat is zo simpel als, even de Git Core installeren en een SSH Key toevoegen en klaar.

En aangezien de meeste mensen die Git gebruiken, technisch onderlegde mensen zijn moet dit wel lukken neem ik aan.

[Armada651]

Git heeft niks te maken met die tools. Git is decentraal, het probleem is dat die tools zich allemaal centraliseren rond GitHub in plaats van onafhankelijk zijn van waar de repository wordt gehost.

[Reactie gewijzigd door Armada651 op 22 juli 2024 23:40]

[timvisee]

Excuus, het was niet de bedoeling om de indruk te geven dat Git/repositories zelf gecentraliseerd werden. Maar inderdaad dat tools zich aan GitHub hechten als centraal hosting platform voor Git repositories.

[Reactie gewijzigd door timvisee op 22 juli 2024 23:40]

[The Third Man]

Het centraliseert niet Git, het is een hostingprovider die git ondersteunt. Bij alle on-line hosting geldt dat als die plat is, alles wat die on-line host gebruikt ook plat is, ongeacht welk protocol je gebruikt om de hosting te beheren. Als je dat niet wilt moet je zelf gaan hosten of een mirror draaien met een CDN etc.

[R4gnax]

Git is decentraal, dus als Github even down is kan je gewoon pushen / pullen naar/van elkaars werkplek.

Dan zal iedereen toch echt z'n eigen Git server moeten draaien naast een Git client en zul je iedereen als upstream tracking branch moeten gaan toevoegen.

En als je dat eenmaal allemaal op touw hebt gekregen (en tegen die tijd de storing nog niet verholpen is...) kom je er op eens achter dat het een hel wordt om je commit history nog een beetje op orde te houden in zo'n situatie.

Het decentrale character van Git betekent dat jij zelf een lokale repository op je eigen systeem hebt die aan een upstream verbonden kan worden die als single-truth geldt, welke op zijn beurt weer doorverbonden kan worden aan een andere. En zo kan zich een boom vormen. Het is echter totaal niet bedoeld om met een breed scala aan meerdere upstreams tegelijkertijd te werken. Misschien dat dat kleinschalig met een paar man nog gaat, maar het zal ho-pe-loos fout gaan zodra je opschaalt.

Wil je zoiets als dit doen, dan moet je alles inrichten om zelf één centrale Git server te draaien en vanuit die server kun je dan een service zoals Github als upstream toevoegen en periodiek upstream merges doen. Feitelijk gebruik je die upstream service dan nog enkel als (evt. publieke) mirror, en meer niet.

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:40]

[aikebah]

Dan zal iedereen toch echt z'n eigen Git server moeten draaien naast een Git client

Nee hoor, geen Git server nodig, enkel een toegankelijke file-share waarop je clone staat.

abu:NetBeansProjects aikebah$ git clone DependencyCheck/.git trial
Cloning into 'trial'...
done.
Checking out files: 100% (890/890), done.
abu:NetBeansProjects aikebah$ cd trial/
abu:trial aikebah$ ls
LICENSE.txt archetype maven
NOTICE.txt build-reporting pom.xml
README.md cli publish_docker.sh
RELEASE_NOTES.md core src
ant coverity_scan.sh utils
abu:trial aikebah$ git status
On branch issue-1527
Your branch is up to date with 'origin/issue-1527'.

nothing to commit, working tree clean
abu:trial aikebah$ git remote -v
origin /Users/aikebah/NetBeansProjects/DependencyCheck/.git (fetch)
origin /Users/aikebah/NetBeansProjects/DependencyCheck/.git (push)

en zul je iedereen als upstream tracking branch moeten gaan toevoegen.

Alleen diegenen van wie je tussentijds werk wilt kunnen pullen of naar wie je tussentijds werk wilt pushen, eventueel kun je er zelfs voor kiezen om een van de repositories naar een bare repo te clonen en die op een fileshare te gebruiken als de central repo waar iedereen mee synct / naar pusht / van pullt.

[R4gnax]

Nee hoor, geen Git server nodig, enkel een toegankelijke file-share waarop je clone staat.

Ah natuurlijk. Ik was inderdaad even vergeten dat je andere locaties op hetzelfde file-systeem - incl. netwerklocaties - ook als remote kunt koppelen.

En inderdaad, dan lijkt me:

eventueel kun je er zelfs voor kiezen om een van de repositories naar een bare repo te clonen en die op een fileshare te gebruiken als de central repo waar iedereen mee synct / naar pusht / van pullt.

-- sowieso een goed idee, tegenover het wilde westen waar iedereen remotes naar elkaar gaat aanleggen.

Een probleem wat daarbij wel blijft bestaan, lijkt me dan dat het nog steeds niet mogelijk is om daarmee simpel meerdere branches bij te gaan houden. Een remote op een file share is vziw wel nog steeds een enkele branch en niet de hele tree. Toch?

Het zou dan misschien kunnen werken als je een vrij plat ontwikkelmodel aanhoudt, en als je zo weinig actieve branches hebt dat je met het handje er allemaal losse remotes voor kunt gaan opzetten, maar dan nog denk ik al gauw aan de woorden: "Just because you can, doesn't mean you should."

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:40]

[aikebah]

Nope, iedere git clone heeft sowieso al info over alle commits en alle branches, zelfs je local clone heeft die (in de .git folder) beschikbaar - dat wil zeggen... alle commits en branches die al aanwezig waren bij je laatste fetch

Enkel de workspace in je local clone is beperkt tot de files die horen bij een specifieke commit (die meestal de HEAD commit van een handig gekozen branch zal zijn)

zie ook https://git-scm.com/book/...#_getting_git_on_a_server

[sugarcube]

Dit klopt maar deels.
Voor git heb je github niet nodig.

Github heeft ook issue tracker, notificaties, etc... Deze staan los van git, maar vormen wel de grote added value.

Ik ben zonet een uur kwijt omdat ik een issue probeerde te rapporteren, en als ik dan "submit" klik, ineens alles weg. proberen support ticket te openen, werkt ook niet: "your browser did something unexpected".

ik had beter even wat meer op tweakers rondgehangen dan had ik vooraf geweten dat ik niet naar github moest gaan

[jfdaniels]

Kan te maken hebben met de oude versie die tijdelijk ronding. Misschien verschijnt je update alsnog binnen een tijdje

[Verwijderd]

Toch vervelend als je afhankelijk bent van Github en daardoor je werk niet kunt doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

Toch vervelend als je afhankelijk bent van stroom en door een stroomstoring je werkt niet kunt doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

Hoeveel kantoorpanden zijn uitgerust met een backup? Hoe ver wil je gaan?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:40]

[mkools24]

Meeste ontwikkelaars werken toch wel op een laptop? Dus ook zonder stroom kun je toch nog minstens wel een paar uur door

[wica]

Werd github alleen maar gebruikt door en voor ontwikkelaars.
Maar er komen steeds meer systemen, die in de flow github geïntegreerd hebben in hun systemen.
Onder anderen, als een nieuwe server op komt, dat deze geheel automatisch een git pull doet, omdat de laatste software en config binnen te halen.

Voor dit soort systemen, kan het behoorlijk vervelend zijn, als github niet goed werkt.

[mkools24]

Als iets down is is het altijd wel vervelend voor iets of iemand maar het is geen drama. Tegenwoordig wordt er direct zo dramatisch gedaan als iets er even uit ligt, vroeger was dat constant zo in de Win 3.11/95 tijd.

[Crazy D]

Ja vroeger was het ook normaal om 4 x per dag een blue screen te hebben maar dat maakt het nog niet meteen acceptabel.

[mkools24]

Precies en toen zeurde niemand want men was het gewend. Tegenwoordig zijn er relatief gezien zo weinig storingen dus als het dan een keer down is dan is is het direct voorpagina nieuws.

[YopY]

Dan moeten ze een SLA met github afsluiten, wat GH natuurlijk niet gaat doen. Als bedrijven dan het risico nemen om een afhankelijkheid te hebben met een systeem zonder SLA is dat hun eigen risico.

[royb3]

Wat heb je aan een laptop als het koffiezetapparaat niet werkt?

[DeTeraarist]

Compiler aan het werk zetten en de koffie op je laptop warm maken?

[jeroen3]

Toch vervelend als je afhankelijk bent van je kantoorgebouw om je werk te doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

Hoeveel bedrijven hebben reserve kantoorgebouwen?

Je kunt dit heel ver doortrekken, maar uiteindelijk moet je gewoon naar de kosten kijken. Github is een aantrekkelijke tool. En zoals alle gereedschap kan het defect. Dan kijk je naar de kosten van downtime en of je die risico's aanvaard.

[The Zep Man]

Toch vervelend als je afhankelijk bent van je kantoorgebouw om je werk te doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

Hoeveel bedrijven hebben reserve kantoorgebouwen?

Er zijn kleine bedrijven die als noodplan de lokale McDonald's hebben (o.i.d. met internetverbinding en koffie), of natuurlijk gewoon thuiswerken. Misschien niet comfortabel, maar het werk kan gewoon doorgaan. Betreft een minimale investering, omdat je alleen maar een plan hoeft te schrijven en uit te voeren wanneer nodig.

Voor programmeerclubs is afhankelijkheid van een kantoorgebouw een stuk minder dan van code repositories.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 23:40]

[Paralectic]

Hoe zou je een alternatief inrichten voor wanneer Github niet meer werkt?

[FreshMaker]

Hoe zou je een alternatief inrichten voor wanneer Github niet meer werkt?

https://www.linux.com/learn/how-run-your-own-git-server

Geen alternatief, maar in eigen beheer houden ..

[incapable]

Ik ben er vrij zeker van dat dit minder zekerheid geeft ivm een gebrek aan redundantie. Als je het samen met github gebruikt door 2 kanten uit te pushen, dan helpt het wel natuurlijk maar toch.

Daarnaast zijn er bijzonder veel software bedrijven zonder daadwerkelijke sysadmins, waardoor git hosters veel interessanter zijn om op te draaien. Zoals anderen ook al noemen, het is verstandiger gewoon 2 of meer grote hosters te gebruiken.

[FreshMaker]

Waarom zou dit minder redundantie geven ?
Je maakt zoals alles een inschatting wat je nodig hebt.
Heb jij genoeg aan één server, zet je er één weg, en maak je dagelijks eenbackup
Is redundantie een noodzaak, zet je op twee of meer plekken een servertje weg, je huurt een VPS bij een aanbieder en plant daar je zaadjes.

Wij hebben een paar dingetjes voor collega's op een fileserver ( geen git ) maar na een paar maanden bleek het soms niet bereikbaar te zijn.
Nu staat er een backuplocatie bij een collega in de meterkast, eenvoudig opgezet met cloudsync en nextcloud, 2 simpele Synology-units die elkaar in het oog houden.
Zelfs Git is beschikbaar voor deze apparaten.

[incapable]

Simpelweg omdat jij niet dezelfde hoeveelheid aan databeveiliging en verbindingszekerheid kunt bieden met een eigen platform, omdat je in dat geval een X aantal servers inricht om dit voor je toen doen. Bij een platform als github/gitlab/etc praat je over een hele infrastructuur die specifiek daarvoor is ingericht. Tuurlijk kan het een keer gebeuren zoals vandaag dat er een zich toch een globaal probleem zicht voordoet, maar normaal gesproken ben je veel minder afhankelijk van hardwarefalen en vooral, het falen van een gehele locatie.

Het grootste probleem blijft natuurlijk alsnog dat je het zelf gaat moeten beheren, en problemen met de servers ook echt jouw probleem zijn

[WhatsappHack]

Dat jij dat niet kan wil niet zeggen dat anderen dat ook niet kunnen... Dat terwijl het nogal simpel om te doen is met git eigenlijk. Het grote voordeel van GitHub is slechts de community imho.

Trouwens, ook als je op GH host kan je maar beter backups maken en een eigen fallback hebben voor als het mis gaat bij GH. Of mirrored hosten bij een 2e partij als Gitlab.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:40]

[Cartman!]

Nu staat er een backuplocatie bij een collega in de meterkast, eenvoudig opgezet met cloudsync en nextcloud, 2 simpele Synology-units die elkaar in het oog houden.

Dat klinkt als een bedrijfje van misschien 4 personen; een bedrijf dat zich serieus bezig houdt met development kan natuurlijk hier niet op vertrouwen.

[FreshMaker]

Het ging niet om hetgeen WAT er gedeeld wordt, maar dat redundantie niet persé hoeft te betekenen dat je 1000 servers in de lucht moet hebben
Dat je als 'aanbieder' je keuze moet maken hoe je iets opzet, en je niet persé afhankelijk hoeft te zijn van een aanbieder extern

[incapable]

Hoewel ik het in grote lijnen met je eens ben, is het enigzins moeilijk om een betrouwbare off-site locatie te hebben voor kleinere bedrijven. Daarnaast ben je niet echt afhankelijk van een partij als je zorgt dat je je data op meerdere plaatsen hebt, dus in-house en/of 1/meerdere aanbieder(s). Simpelweg vertrouwen op 1 aanbieder gaat hetzelfde probleem opleveren natuurlijk

[TheVivaldi]

Toch zijn er grote projecten die het zo doen. GNOME bijv. gebruikt GitLab (en daarvoor hun eigen Git-server), maar gebruikt GitHub als spiegelserver (mirror). En Wuhan Deepin Technology idem dito: die hebben hun eigen Git-server (op basis van Gerrit), maar gebruiken GitHub als spiegelserver. En zo zijn er nog wel grote projecten en bedrijven die het zo aanpakken. Blijkbaar doen die het allemaal verkeerd i.v.m. gebrek aan redundatie?

[incapable]

Ik denk dat ik ergens iets verkeerd opgepakt heb, want mijn reactie was voornamelijk bedoeld voor een situatie waarin geheel op eigen servers word gedraaid ipv als mirror, of als een opstelling waar een remote mirror voor ingesteld staat. In dat geval maakt het qua redundantie natuurlijk niet uit

[aikebah]

Hoeveel meer redundantie wil je hebben dan een volledige clone van je repository history op de laptop van iedere developer?

[jesse!]

Door Git zelf te hosten, bij de drie grootste kan dit eenvoudig (GitHub, GitLab en Atlassian)

[SwerveShot]

Git hosten zal niet het issue zijn. Maar tracken van issues bijvoorbeeld is wel een platform specifieke feature. Dat migreer je volgens mij niet zomaar van GitHub naar GitLab.

[jesse!]

Als je Git zelf host met een van die drie partijen die ik noem, zit er ook een issuetracker bij.

[SwerveShot]

Okay, zover was ik ook. Maar bestaande issues importeren van de een naar het andere platform wordt een beetje lastig denk ik. Als je geluk hebt werkt dat tussen een publieke en lokale instance van Gitlab.

[The Zep Man]

Je kan in GitLab ook pull requests en issues vanuit GitHub importeren, samen met andere extra informatie.

[SwerveShot]

Oh nice! Weer wat geleerd. Nou moet GitHub wel beschikbaar zijn om dat te kunnen doen natuurlijk.

[Idiocracy]

We hebben met https://github.com/xbmc een van de grootste opensoure Github repos en hebben als test gedient om github naar gitlab migratie te doen. Initieel werkte dit niet vanwege de groote maar Gitlab heeft dit gefixed. Tot nu toe zitten we nog steeds bij Github omdat alles te migreren van het project veel tijd in beslag neemt en ook iedereen moet daarmee over naar gitlab.

[TheVivaldi]

Natuurlijk kan dat wel. GNOME heeft dat onlangs nog bewezen en die draaiden voorheen zelfs hun eigen Git-server, dus als het van hun eigen Git naar GitLab kan, dan kan het zeker van GitHub naar GitLab.

[BugBoy]

Gitlab is een uitstekend product dat met relatief weinig effort lokaal gehost kan worden. Wij draaien Gitlab in een Docker image op één van onze Linux servers en dat werkt perfect. Het grote voordeel is dat je ook meteen kunt integreren op AD en dus niet overal weer verschillende accounts hebt.

[TheVivaldi]

Vind ik ook, GitLab is erg fijn! Het enige nadeel vind ik, en daar heeft GitHub dan weer het voordeel, dat pull requests doen iets omslachtiger is.

[Lord Anubis]

door het niet zelf te hosten, maar laten syncen tussen de grootste drie?
Zijn daar tools voor?

[frickY]

Zorgen dat je een lokale cache/mirror hebt van al je dependencies.

Dat je even geen nieuwe functionaliteiten kunt toevoegen is vervelend. Maar als je geen releases van bestaande code kunt doen, heb je ergens eens steek laten vallen.

[Bas_f]

Dit is een van de redenen waarom wij zelf onze repo's hosten.

[Snow_King]

En die gaan nooit down?

[kaas-schaaf]

Het is niet zo zwart wit maar de "Die gaat nooit down?" is net zo kort door de bocht als "wij hosten dat daarom zelf".

Als voorbeeld (non exhaustive): Je hebt controle meer over de uptime: Je kan zelf ook kiezen om de boel in een high availability platform te hangen en daar weer redundancy over te brengen. Bijvoorbeeld over meerdere high availability platformen gemirrord. Maar allen als je source control high availability moet hebben met hogere garanties dan de 99.95% die github aanbied of met andere redenen.

Veelal wordt ook gekozen voor de simpelere (en niet per definitie mindere/foute) oplossing door de SLA van github aan te nemen. In heel veel gevallen is een 3x9 uptime accepteren als bedrijf omdat je zelf ook geen hogere response bied. En als de de premium neemt krijg je een 99.95% uptime met 8 hour response (wel 24/5) wat neer komt op een max 4.5 uur downtime per jaar waarna je de consequenties in ieder geval kan gaan doortrekken.

Mocht je dat niet kunnen/willen zit je in een andere categorie en ga je het wel zelf doen.

edit: textueel

[Snow_King]

Zo zwart-wit is het niet, maar zo stellen veel mensen het wel.

Zelf hosten kost geld, mensen en tijd. Daar hebben veel organisaties geen resources voor, dus hosten ze het ergens extern. Daar ligt vaak wel de kennis en expertise.

Je kan nu eenmaal niet alles in-house doen.

[TommyboyNL]

Ongetwijfeld gaan die wel eens down. Het is echter een stuk makkelijker en sneller om een "kleine" lokale repo te herstellen (VMware snapshot terugzetten bijvoorbeeld...) dan een beest als Github.

[Verwijderd]

Makkelijker voor wie? Voor mij (en ik vermoed jou) zal het makkelijker zijn. Maar ik kom regelmatig bij ontwikkelaars over de vloer waar 3 jaar geleden iemand ooit eens wat handigs op een server heeft geïnstalleerd en dat nu niet meer werkt. Hebben ze 3 jaar lang een tientje in de maand uitgespaard en mogen ze die nu alsnog aan mij betalen om het weer te herstellen. Ik begrijp dat soort keuzes niet zo goed..

[CAPSLOCK2000]

Makkelijker voor wie? Voor mij (en ik vermoed jou) zal het makkelijker zijn. Maar ik kom regelmatig bij ontwikkelaars over de vloer waar 3 jaar geleden iemand ooit eens wat handigs op een server heeft geïnstalleerd en dat nu niet meer werkt. Hebben ze 3 jaar lang een tientje in de maand uitgespaard en mogen ze die nu alsnog aan mij betalen om het weer te herstellen. Ik begrijp dat soort keuzes niet zo goed..

Makkelijk is niet hetzelfde als goedkoop of betrouwbaar.
Voor die developers is het nog steeds enorm makkelijk. Zij hebben een probleem en jij lost het op. Makkelijk zat.
Het kost wat, maar in deze discussie waren we niet op zoek naar de goedkoopste oplossing.

De fout die ze maken is dat ze niet voldoende investeren in het gereedschap dat ze nodig hebben om hun werk te doen. Als ze niet genoeg willen betalen om kwaliteit te krijgen (in geld, tijd en/of kennis) dan wordt het natuurlijk nooit wat. Dat staat los van de vraag of ze dat beter lokaal of remote kunnen doen.

[Kees]

In het algemeen kun je daar veel meer aan doen dan duimen draaien en wachten op een grote partij als Github.

Maar gelukkig is git niet afhankelijk van 1 partij, als github plat ligt zet je gewoon tijdelijk even iets anders op, of je pushed je changes gewoon nog niet. Je hoeft niet te gaan zitten wachten totdat github terug is

[CAPSLOCK2000]

Voor mij is het verschil dat ik bij m'n eigen spullen zelf kan bepalen hoeveel moeite er wordt gestoken in het oplossen van problemen. Ik heb te vaak gehoord "heel vervelend, upgrade eerst maar naar de nieuwste firmware en dan kunt u maandag een intake-formulier invullen".
Als ik het zelf in beheer heb kan ik zelf bepalen hoe ver ik wil gaan met recovery. Het kost misschien een flinke cent, maar ik heb de keuze.

[Snow_King]

Klopt helemaal! Maar niet elke organisatie wil/kan die centen uit geven en kiezen daarom voor uitbesteden.

Lokaal draaien is niet altijd persé beter, je moet wel bereid zijn de tijd, geld en moeite er in te steken.

[Alw4ysFresh]

Ik zou eerder altijd een back-up gebruiken door je eigen repo's te hosten en het op GitHub te plaatsen. En ik denk zoals @Snow_King schrijft dat jullie host eerder down gaat dan GitHub.

[Keypunchie]

Mooi moment voor Developers om eens een keer aan hun documentatie te gaan werken

Vervelend als een dienst down is, maar volgens mij is de algemene uptime van Github prima. Daarnaast betekent dit niet echt dat je niet kunt werken, alleen dat je nu geen code kunt mergen* of binnenhalen. Met je lokale kopie kun je nog steeds aan de slag.

*Ik ben maar een van origine Ops'er die nog niet helemaal doorgewinterd is in DevOps, dus 'correct me if I'm wrong!

[Reactie gewijzigd door Keypunchie op 22 juli 2024 23:40]

[FreshMaker]

Ik had er gisteren wat last van, in de ochtend kwamen de repositories niet binnen, later op de middag kon ik de install gewoon afmaken.

Helaas was hierdoor ook de manual-pagina niet bereikbaar..

[JorzoR]

Toch vervelend als je afhankelijk bent van Github en daardoor je werk niet kunt doen. Maar eigenlijk als dit het geval is, dan ben jij, je team, je bedrijf verkeerd bezig. Zorg dat je altijd een alternatief hebt.

Tja, zo valt er voor alles wel wat te zeggen. Zo vaak is GitHub niet down. Alternatief is zelf hosten, maar het is een illusie dat dat nooit down is.

Mijn ervaring met Github downtimes; komt niet vaak voor. Is vervelend als het wel voorkomt, maar je kan gewoon doorwerken op je locale repo. Financiele "schade" is daardoor minimaal, en te verwaarlozen met de resources die het kost om een Git backup parallel te laten draaien en onderhouden. Keuze snel gemaakt dus

[HooksForFeet]

Lekker makkelijk gezegd dit. Zoiets is in theorie leuk, maar de praktijk valt toch altijd net effe wat meer tegen.

[Zeror]

Als het tegenvalt, doe je iets verkeerd. Als je enorm afhankelijk bent van GitHub en geen alternatief hebt, dan heb, zoals dat in scrum heet, een truckfactor van 1. En dat is nooit goed. Het is daarom goed om te zorgen voor een alternatief in wat voor vorm dan ook.
Bijvoorbeeld: Naast het push//pull/commit op GitHub zou je de scriptfiles bijv. ook nog kunnen dupliceren naar een centrale netwerklocatie waar jij en jouw team bij kunnen (bijvoorbeeld). Al doe je dat laatste enkel maar om files te archiveren. Mocht het dan gebeuren dat GitHub down is, kun je op die files terugvallen.

[Gopher]

Low bus factor is het toch?

Wat bedoel je met script files? De sourcecode? Want die heeft toch iedere dev lokaal, en als 't moet kun je van andermans systeem pullen. Gelukkig werkt de Git repo gewoon, maar heeft met name de site issues.

[SuperDre]

Er kan altijd iets gebeuren, ook bij een lokale server kan zoiets voorkomen. Zo simpel is het niet om hiervoor een alternatief te hebben voor het geval zoiets gebeurd. Enige waar je op kunt hopen is dat het snel opgelost is, en dat je niet dagen er uit ligt (zelfs natuurlijk geen uren).

[Gopher]

Het is overigens ook niet zo dat commits niet werken.

Tenminste dat probleem ervaren wij niet (De organisatie waar ik momenteel voor werk host alle code op github).

Wat niet werkt, zijn Pull request schermen e.d. Daar gebeurd vanalles raars.

Helaas, even wachten met features mergen, gelukkig is morgen pas de Demo :-).

[Osiummaster]

Dat is dus wel een ineffiencte manier van werken. Om ALLES in je workflow zelf te bouwen in plaats van heb in handen te leggen van een giga corporatie gaat klauwen aan klauwen met geld en development time kosten.

Sterker nog, het is vele malen sneller om zoveel mogelijk tools welke bijna elke developer gebruiks te outsourcen. Als slechts 1 bedrijf hier verantwoordelijk voor is ipv dat iedereen zijn eigen oplossing gaat bouwen, kan men hier gezamelijk voor betalen en ben je dus veel goedkoper uit. Om hier niet aan mee te doen omdat je niet afhankelijk wil zijn klinkt leuk, maar als je niet een enorm groot bedrijf bent zie ik dit niet als feasible.

Als je bijvoorbeeld een website hebt welke een icon template uit een GIT repository gebruikt of om de CSS layout te bepalen, is het veel handiger om file uit een GitHub repo te linken omdat je site altijd automatisch de nieuwste versies zal pullen en je zelf niks handmatig hoeft te updaten.

Ja, je hebt een gevoel van veiligheid door het zelf in handen te hebben, maar ergens blijf je zelf afhankelijk van externe partijen. Om uncommon tools te outsourcen is geen sterk idee. Maar op grote partijen zoals GitHub zal je gewoon moeten rekenen en de downtime voor lief nemen.

[NLxDoDge]

Gelukkig kunnen we altijd zelf een git server opzetten met back-ups

[SuperDre]

En wat doe je als die dan dus down gaat? dus dan zit je met hetzelfde probleem als nu met github is gebeurd.

[YopY]

Maar is dat goedkoper en beter dan de $9/gebruiker/maand die Github vraagt?

[Ventieldopje]

Jep.. pak een VPS voor een tientje, installeer SSH en Git en done. Je zou zelfs een git repo kunnen hosten op je smartwatch of koelkast.

[Gopher]

Raspberry PI, en die kun je backups laten maken naar een andere PI etc. etc.

[SwerveShot]

Als de overname door Microsoft nu wordt goedgekeurd door alle toezichthouders kunnen ze de boel zo naar Azure migreren.
Maar een terecht punt van @Zeror; zoiets belangrijks als code zou je altijd een alternatief voor moeten hebben. Gelukkig is git erg goed geschikt voor decentrale opslag. Dus je kunt de boel zo uploaden naar een andere service zoals Gitlab. Daarvan kun je ook mooi een lokale instance hosten.

[Reactie gewijzigd door SwerveShot op 22 juli 2024 23:40]

[YopY]

Ik hoor anders niet veel goede geluiden over uptime van Azure, kan aan mijn bubbel liggen.

[batjes]

Zal aan jouw bubbel liggen.

2017 global uptime:
Azure: 99,9982%
AWS: 99,9746%

[SuperDre]

Maar dan moet je dus wel elke push naar beide services doen, en lokaal hosten is natuurlijk ook risicovol.

[Koen Hendriks]

Je kunt gewoon meerdere remotes zetten voor 1 repo, dan gewoon ineenkeer pushen naar beide

[flowerhack]

En ik maar proberen om een Pull Request aan te maken
Het had wel prettig geweest als ze dit ook even op de github homepage hadden gemeld

[Hiub]

De homepage heb je niet veel aan als een site down is, daarom hebben veel websites een status page die daar volledig los van staat. En die je dus gisteren beter even had kunnen checken: https://status.github.com/messages

[Jeoh]

Onderdelen van GitHub kampen met downtime:

[..] this incident only impacted website metadata stored in our MySQL databases, such as issues and pull requests. Git repository data remains unaffected and has been available throughout the incident.

Je kan dus nog gewoon prima je commits doen en bij je repositories komen, alleen kan je niet bij de PRs en Issues. Big deal.

[HollowGamer]

Dat is een big deal, ik durf te wetten dat PR's en de issue tracker één van de belangrijkste features zijn om GitHub te gebruiken, zeker met teams is dit handig en nodig (wat moet er worden gedaan, ontwikkelingen, debuggen, etc.). In sommige gevallen wil je die PR er wel in hebben of het even goed kunnen reviwen. Genoeg dus waarbij de development in zo'n gevallen wat moeilijker gaat.

Het enige wat je zou kunnen doen is je git code syncen tussen partijen, maar volgensmij behoort daar de issue/bug/wiki niet echt bij.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 23:40]

[NaliXL]

Peentjes zweten voor systeembeheerders. Ik kan alleen maar met ze meeleven.
Heel vervelend van de downtime, maar zo'n groot platform draaiend houden is geen peulenschilletje, en ik geloof niet dat github er vaak uit ligt.

[Rob Coops]

Ach het maakt weinig uit de local repo werkt gewoon goed de central repo is niet echt nodig om progressie te boeken. En er zijn genoeg andere dingen te doen als developer waarbij het niet nodig is om steeds maar met de centrale repo te kletsen.

Werkend bij een bedrijf dat alles in Github heeft staan merk ik er maar weinig van. Natuurlijk zijn er mensen die claimen niet te kunnen werken maar als ik ze dan vraag naar dingen zo als documentatie dan wel simpel weg lokaal werken en een dagje zonder CICD te doen dan blijkt op eens dat het allemaal niet zo erg is.

[pepijnm]

"In juni maakte Microsoft bekend GitHub over te willen nemen, voor 7,5 miljard dollar."

Snap niet wrm dit er onder moet staan. Zie niet de link tussen het opslagsysteem en de overname.