Direkter vun Operatiounen vun Banki.ru Portal Andrey Nikolsky geschwat op d'lescht Joer Konferenz iwwer Orphan Servicer: wéi een en Orphan an der Infrastruktur z'identifizéieren, firwat Orphan Services schlecht sinn, wat mat hinnen ze maachen, a wat ze maachen wann näischt hëlleft.
Ënnert dem Schnëtt ass eng Textversioun vum Bericht.
Moien Kollegen! Mäin Numm ass Andrey, ech Chef Operatiounen um Banki.ru.
Mir hu grouss Servicer, dat sinn esou monolithesch Servicer, et gëtt Servicer an engem méi klassesche Sënn, an et gi ganz kleng. A menger Aarbechter-Bauer Terminologie soen ech datt wann e Service einfach a kleng ass, dann ass et Mikro, a wann en net ganz einfach a kleng ass, dann ass et just e Service.
Virdeeler vun Servicer
Ech wäert séier iwwer d'Virdeeler vun de Servicer goen.
Déi éischt ass Skaléieren. Dir kënnt séier eppes op de Service maachen an d'Produktioun starten. Dir hutt Traffic kritt, Dir hutt de Service gekloont. Dir hutt méi Traffic, Dir hutt et gekloont a liewen domat. Dëst ass e gudde Bonus, an am Prinzip, wéi mir ugefaang hunn, gouf et fir eis als Wichtegst ugesinn, firwat mir dat alles maachen.
Zweetens, isoléiert Entwécklung, wann Dir e puer Entwécklungsteams hutt, e puer verschidden Entwéckler an all Team, an all Team entwéckelt säin eegene Service.
Mat Équipë gëtt et eng Nuance. Entwéckler sinn anescht. An et gëtt z.B. . Ech hunn dat éischt mam Maxim Dorofeev gesinn. Heiansdo Schneeflocke Leit sinn op e puer Équipen an net op anerer. Dëst mécht déi verschidde Servicer, déi iwwer d'Firma benotzt ginn, e bëssen ongläich.
Kuckt d'Bild: dëst ass e gudden Entwéckler, hien huet grouss Hänn, hie ka vill maachen. Den Haaptproblem ass wou dës Hänn hierkommen.
Servicer maachen et méiglech verschidde Programméierungssproochen ze benotzen déi méi gëeegent sinn fir verschidden Aufgaben. E puer Service ass am Go, e puer ass an Erlang, e puer ass am Ruby, eppes ass am PHP, eppes ass am Python. Am Allgemengen kënnt Dir ganz wäit ausbauen. Et ginn och Nuancen hei.
Serviceorientéiert Architektur geet virun allem ëm Devops. Dat ass, wann Dir keng Automatisatioun hutt, gëtt et keen Deploymentprozess, wann Dir et manuell konfiguréiert, kënnen Är Konfiguratioune vu Serviceinstanz zu Instanz änneren, an Dir musst dohinner goen fir eppes ze maachen, da sidd Dir an der Häll.
Zum Beispill, Dir hutt 20 Servicer an Dir musst mat der Hand ofsetzen, Dir hutt 20 Konsolen, an Dir dréckt gläichzäiteg "Enter" wéi en Ninja. Et ass net ganz gutt.
Wann Dir e Service no Testen hutt (wann et Testen ass, natierlech), an Dir musst et nach mat engem Fichier fäerdeg maachen, sou datt et an der Produktioun funktionnéiert, hunn ech och schlecht Nouvelle fir Iech.
Wann Dir op spezifesch Amazon Servicer vertrauen an a Russland schafft, dann hat Dir virun zwee Méint och "Alles ronderëm ass a Brand, ech sinn gutt, alles ass cool."
Mir benotzen Ansible fir d'Deployment ze automatiséieren, Puppet fir Konvergenz, Bambus fir d'Deployment ze automatiséieren, a Confluence fir iergendwéi alles ze beschreiwen.
Ech wäert net op dat am Detail ophalen, well de Rapport méi iwwer Interaktiounspraktiken geet, an net iwwer technesch Ëmsetzung.
Zum Beispill hu mir Problemer, wou Puppet op de Server mat Ruby 2 funktionnéiert, awer e puer Applikatioun ass fir Ruby 1.8 geschriwwen, a si schaffen net zesummen. Do geet eppes falsch. A wann Dir musst verschidde Versioune vu Ruby op enger Maschinn lafen, fänkt Dir normalerweis Problemer ze hunn.
Zum Beispill gi mir all Entwéckler eng Plattform op där et ongeféier alles ass wat mir hunn, all d'Servicer déi kënne entwéckelt ginn, sou datt hien en isoléiert Ëmfeld huet, hien kann et briechen a bauen wéi e wëll.
Et geschitt datt Dir e speziell kompiléierte Package braucht mat Ënnerstëtzung fir eppes do. Et ass zimlech haart. Ech hunn e Bericht gelauschtert wou den Docker Bild 45 GB weit. Am Linux ass et natierlech méi einfach, alles ass méi kleng do, awer trotzdem gëtt et net genuch Plaz.
Gutt, et gi konfliktend Ofhängegkeeten, wann ee Stéck vum Projet vun enger Bibliothéik vun enger Versioun hänkt, hänkt en anert Stéck vum Projet vun enger anerer Versioun of, an d'Bibliothéike sinn guer net zesumme installéiert.
Mir hunn Siten a Servicer am PHP 5.6, mir schummen eis vun hinnen, mee wat kënne mir maachen? Dëst ass eisen eenzege Site. Et gi Siten a Servicer op PHP 7, et gi méi vun hinnen, mir schummen eis net vun hinnen. An all Entwéckler huet seng eege Basis, wou hien glécklech gesäit.
Wann Dir an enger Firma an enger Sprooch schreift, da kléngt dräi virtuell Maschinnen pro Entwéckler normal. Wann Dir verschidde Programméierungssproochen hutt, da gëtt d'Situatioun verschlechtert.
Dir hutt Siten a Servicer op dëser, op dëser, dann eng aner Site fir Go, ee Site fir Ruby, an e puer aner Redis op der Säit. Als Resultat gëtt all dëst an e grousst Feld fir Ënnerstëtzung, an déi ganz Zäit kann e puer dovun briechen.
Dofir hu mir d'Virdeeler vun der Programméierungssprooch ersat duerch d'Benotzung vu verschiddene Kaderen, well PHP-Frameworks ganz ënnerschiddlech sinn, si hu verschidde Fäegkeeten, verschidde Gemeinschaften a verschidde Ënnerstëtzung. An Dir kënnt e Service schreiwen, fir datt Dir schonn eppes prett hutt.
All Service huet seng eegen Equipe
Eisen Haaptvirdeel, deen sech iwwer e puer Joer kristalliséiert huet, ass datt all Service säin eegent Team huet. Dëst ass bequem fir e grousse Projet, Dir kënnt Zäit op Dokumentatioun spueren, Manager kennen hire Projet gutt.
Dir kënnt einfach Aufgaben vun der Ënnerstëtzung ofginn. Zum Beispill ass de Versécherungsservice futti gemaach. An direkt geet d'Equipe, déi sech mat Versécherung beschäftegt, fir se ze fixéieren.
Nei Features gi séier erstallt, well wann Dir een Atomdéngscht hutt, kënnt Dir séier eppes dran schrauwen.
A wann Dir Äre Service brécht, an dëst zwangsleefeg passéiert, hutt Dir d'Servicer vun anere Leit net beaflosst, an Entwéckler mat Bits vun aneren Teams kommen net bei Iech lafen a soen: "Oh, maacht dat net."
Wéi ëmmer ginn et Nuancen. Mir hunn stabil Teams, Manager ginn un d'Team genoelt. Et gi kloer Dokumenter, Manager iwwerwaachen alles genau. All Team mat engem Manager huet verschidde Servicer, an et gëtt e spezifesche Kompetenzpunkt.
Wann d'Equipen schwiewen (mir benotzen dat och heiansdo), gëtt et eng gutt Method déi "Star Map" genannt gëtt.
Dir hutt eng Lëscht vu Servicer a Leit. En Asterisk bedeit datt d'Persoun en Expert an dësem Service ass, e Buch heescht datt d'Persoun dëse Service studéiert. D'Aufgab vun der Persoun ass d'Buch fir en Asterisk auszetauschen. A wann näischt virun de Service geschriwwe gëtt, da fänken d'Problemer un, iwwer déi ech weider schwätzen.
Wéi erschéngen Orphan Services?
Den éischte Problem, den éischte Wee fir en orphan Service an Ärer Infrastruktur ze kréien ass d'Leit ze brennen. Huet iergendeen jeemools e Geschäft Frist erfëllt ier d'Aufgaben bewäert goufen? Heiansdo geschitt et datt d'Deadline knapp sinn an et ass einfach net genuch Zäit fir Dokumentatioun. "Mir mussen de Service un d'Produktioun iwwerginn, da addéiere mer et."
Wann d'Team kleng ass, geschitt et datt et een Entwéckler gëtt deen alles schreift, de Rescht sinn an de Flilleken. "Ech hunn d'Basisarchitektur geschriwwen, loosst eis d'Interfaces addéieren." Dann iergendwann geet de Manager zum Beispill fort. A während dëser Period, wann de Manager fort ass an en neien nach net ernannt gouf, entscheeden d'Entwéckler selwer wou de Service geet a wat do geschitt. A wéi mir wëssen (loosst eis e puer Rutschen zréckgoen), an e puer Teams ginn et Schneeflocke Leit, heiansdo e Schnéiflack Team Lead. Dann hält hien op, a mir kréien en Orphan Service.
Zur selwechter Zäit verschwannen Aufgaben aus der Ënnerstëtzung an aus dem Geschäft net am Réckstand. Wann et architektonesch Feeler bei der Entwécklung vum Service gouf, kommen se och an de Réckstand. De Service gëtt lues a lues verschlechtert.
Wéi een Orphan z'identifizéieren?
Dës Lëscht beschreift d'Situatioun gutt. Wien huet eppes iwwer hir Infrastruktur geléiert?
Iwwer dokumentéiert Aarbecht-arounds: et gëtt e Service an, am Allgemengen, et funktionnéiert, et huet eng zwee-Säit Handbuch wéi mat him ze schaffen, awer kee weess wéi et dobannen funktionnéiert.
Oder, zum Beispill, gëtt et eng Aart vu Linkverkierzer. Zum Beispill hu mir de Moment dräi Link Shorteners am Gebrauch fir verschidden Zwecker a verschiddene Servicer. Dëst sinn nëmmen d'Konsequenzen.
Elo wäert ech de Kapitän vum offensichtleche sinn. Wat soll gemaach ginn? Als éischt musse mir de Service un en anere Manager transferéieren, en anert Team. Wann Är Teamleader nach net opgehalen ass, dann an dësem aneren Team, wann Dir verstitt datt de Service wéi en Orphan ass, musst Dir een enthalen deen op d'mannst eppes doriwwer versteet.
Den Haapt Saach: Dir musst d'Transferprozeduren am Blutt schreiwen. An eisem Fall iwwerwaachen ech dat normalerweis, well ech brauch alles fir ze schaffen. D'Manager brauchen et fir séier geliwwert ze ginn, a wat duerno geschitt ass fir si net méi sou wichteg.
Deen nächste Wee fir en Orphan ze maachen ass "Mir maachen et outsourcéiert, et wäert méi séier sinn, an da gi mir et un d'Team iwwerginn." Et ass kloer datt jiddereen e puer Pläng an der Equipe huet, en Tour. Dacks denkt e Geschäftsclient datt den Outsourcer déiselwecht Saach maache wéi déi technesch Departement déi d'Firma huet. Obwuel hir Motivatioune sinn anescht. Et gi komesch technologesch Léisungen a komesch algorithmesch Léisungen am Outsourcing.
Zum Beispill hu mir e Service deen Sphinx op verschidden onerwaart Plazen haten. Ech soen Iech herno wat ech hu misse maachen.
Outsourcer hunn selbstgeschriwwene Kaderen. Dëst ass just blo PHP mat Copy-Paste vun engem fréiere Projet, wou Dir all Zorte vu Saachen fannt. Deployment Scripten sinn e groussen Nodeel wann Dir e puer komplex Bash Scripten benotze musst fir e puer Zeilen an enger Datei z'änneren, an dës Deployment Scripte ginn vun engem drëtten Skript genannt. Als Resultat ännert Dir den Deployment System, wielt eppes anescht, hop, awer Äre Service funktionnéiert net. Well do war et néideg 8 méi Linken tëscht verschiddenen Ordner ze setzen. Oder et geschitt, datt dausend records Aarbecht, mä honnertdausend net méi schaffen.
Ech wäert weider Kapitän. En outsourced Service akzeptéieren ass eng obligatoresch Prozedur. Huet iergendeen jeemools en outsourced Service ukomm an net iwwerall ugeholl ginn? Dëst ass net sou populär, natierlech, wéi en orphan Service, awer trotzdem.
De Service muss iwwerpréift ginn, de Service muss iwwerpréift ginn, Passwierder musse geännert ginn. Mir haten e Fall wéi se eis e Service ginn, et gëtt en Admin Panel "wann Login == 'Admin' && Passwuert == 'Admin'...", et ass direkt am Code geschriwwen. Mir sëtzen an denken, a Leit schreiwen dat an 2018?
D'Späicherkapazitéit testen ass och eng noutwendeg Saach. Dir musst kucken wat op honnertdausend records geschitt, och ier Dir dëse Service iergendwou an d'Produktioun setzt.
Et sollt keng Schimmt sinn fir e Service fir Verbesserung ze schécken. Wann Dir seet: "Mir wäerten dëse Service net akzeptéieren, mir hunn 20 Aufgaben, maacht se, da akzeptéiere mir", ass dat normal. Äert Gewësse sollt net verletzt ginn, datt Dir e Manager gräift oder datt d'Geschäft Sue verschwenden. D'Geschäft wäert dann méi ausginn.
Mir haten e Fall wéi mir décidéiert hunn e Pilotprojet auszesoen.
Et gouf op Zäit geliwwert, an dëst war déi eenzeg Qualitéit Critère. Dofir hu mir e weidere Pilotprojet gemaach, deen och net méi wierklech e Pilot war. Dës Servicer goufen ugeholl, an duerch administrativ Moyenen hu se gesot, hei ass Äre Code, hei ass d'Team, hei ass Äre Manager. D'Servicer hunn eigentlech schonn ugefaang e Gewënn ze maachen. Zur selwechter Zäit sinn se tatsächlech nach Weese, kee versteet wéi se schaffen, an d'Manager maachen hiert Bescht fir hir Aufgaben ze verzichten.
Et gëtt en anert super Konzept - Guerilla Entwécklung. Wann e puer Departementer, normalerweis de Marketing Departement, eng Hypothese wëll testen an de ganze Service outsourced bestellt. Den Traffic fängt dran an, si maachen d'Dokumenter zou, ënnerschreiwen Dokumenter mam Optraghueler, kommen a Betrib a soen: "Dudes, mir hunn e Service hei, et huet scho Verkéier, et bréngt eis Suen, loosst eis et akzeptéieren." Mir waren wéi: "Oppa, wéi kann dat sinn."
An eng aner Manéier fir en orphan Service ze kréien: wann e puer Team op eemol iwwerlaascht gëtt, seet d'Gestioun: "Loosst eis de Service vun dëser Equipe an eng aner Equipe transferéieren, et huet eng méi kleng Laascht." An da wäerte mir et op eng drëtt Equipe transferéieren an de Manager änneren. An um Enn hu mir erëm en Orphan.
Wat ass de Problem mat Orphen?
Wien weess net, dëst ass d'Schluechtschëff Wasa a Schweden opgewuess, berühmt fir d'Tatsaach datt et 5 Minutte nom Start sank. An de Kinnek vu Schweden, iwwregens, huet net jiddereen fir dëst ausgefouert. Et gouf vun zwou Generatioune vun Ingenieuren gebaut, déi net wosst wéi esou Schëffer ze bauen. Natierlech Effekt.
D'Schëff kéint iwwregens vill méi schlëmm ënnergoen, zum Beispill, wann de Kinnek schonn iergendwou an engem Stuerm drop gefuer ass. An dofir ass hien direkt erdronk, laut Agile ass et gutt fréi ze versoen.
Wa mir fréi versoen, ginn et normalerweis keng Problemer. Zum Beispill, während der Akzeptanz gouf et fir Revisioun geschéckt. Awer wa mir scho bei der Produktioun versoen, wann Sue investéiert ginn, da kënnen et Problemer ginn. Konsequenzen, wéi se am Geschäft genannt ginn.
Firwat Orphan Servicer geféierlech sinn:
- De Service kann op eemol briechen.
- De Service brauch eng laang Zäit fir ze reparéieren oder ass guer net reparéiert.
- Sécherheetsproblemer.
- Problemer mat Verbesserungen an Aktualiséierungen.
- Wann e wichtege Service brécht, leid de Ruff vun der Firma.
Wat maache mat orphan Servicer?
Ech widderhuelen wat nach eng Kéier ze maachen. Éischt muss et Dokumentatioun ginn. 7 Joer bei Banki.ru huet mir geléiert datt Tester d'Wuert vun den Entwéckler net huelen, an d'Operatiounen d'Wuert vun jidderengem net huelen. Mir mussen kontrolléieren.
Zweetens ass et néideg Interaktiounsdiagrammer ze schreiwen, well et geschitt datt Servicer, déi net ganz gutt ugeholl ginn, Ofhängegkeeten enthalen, iwwer déi keen gesot huet. Zum Beispill hunn d'Entwéckler de Service op hirem Schlëssel fir e puer Yandex.Maps oder Dadata installéiert. Dir hutt lafe fräi Limite, alles ass gebrach, an Dir wësst net wat geschitt ass. All esou rakes muss beschriwwe ginn: de Service benotzt Dadata, SMS, soss eppes.
Drëttens, schaffen mat technesch Schold. Wann Dir eng Aart vu Krutchen maacht oder e Service akzeptéiert a seet datt eppes muss gemaach ginn, musst Dir sécher sinn datt et gemaach gëtt. Well da kann et erausstellen datt dat klengt Lach net sou kleng ass, an Dir fällt duerch.
Mat architektoneschen Aufgaben hu mir eng Geschicht iwwer Sphinx. Ee vun de Servicer benotzt Sphinx Lëschte gitt. Just eng paginéiert Lëscht, awer et gouf all Nuecht nei indexéiert. Et gouf aus zwee Indizes zesummegesat: ee grousse war all Nuecht indexéiert, an et war och e klengen Index, deen drop geschrauft gouf. All Dag, mat enger 50% Wahrscheinlechkeet entweder Bombardementer oder net, ass den Index während der Berechnung erofgefall, an eis Neiegkeeten hunn op der Haaptsäit opgehalen. Fir d'éischt huet et 5 Minutte gedauert bis den Index nei indexéiert gouf, duerno ass den Index gewuess, an iergendwann huet et ugefaang 40 Minutten ze huelen fir nei Index ze maachen. Wa mer dat ofgeschnidden hunn, hu mer en Opschlag gelaacht, well kloer war, datt e bësse méi Zäit passéiert an eisen Index nees vollzäiteg indexéiert gëtt. Dëst wäert e Feeler fir eise Portal sinn, et gëtt keng Neiegkeet fir aacht Stonnen - dat ass et, d'Geschäft huet gestoppt.
Plangt fir mat engem orphan Service ze schaffen
Tatsächlech ass dëst ganz schwéier ze maachen, well devops ass iwwer Kommunikatioun. Dir wëllt gutt mat Äre Kollegen sinn, a wann Dir Äre Kollegen a Manager mat Reglementer iwwer de Kapp schloen, da kënne se widderspréchlech Gefiller vis-à-vis vun deene Leit hunn, déi dat maachen.
Zousätzlech zu all deene Punkte gëtt et nach eng wichteg Saach: spezifesch Leit musse fir all spezifesche Service verantwortlech sinn, fir all spezifesch Sektioun vun der Deploymentprozedur. Wann et keng Leit sinn an Dir musst aner Leit unzéien fir dës ganz Saach ze studéieren, gëtt et schwéier.
Wann dat alles net gehollef huet, an Ären Orphan Service ass nach ëmmer en Orphan, keen wëll et iwwerhuelen, d'Dokumentatioun ass net geschriwwe ginn, d'Equipe, déi an dëse Service geruff gouf, refuséiert eppes ze maachen, et gëtt en einfache Wee - nei nei ze maachen alles.
Dat ass, Dir hëlt d'Ufuerderunge fir de Service nei a schreift en neie Service, besser, op enger besserer Plattform, ouni komesch technologesch Léisungen. An Dir migréiert et an der Schluecht.
Mir haten eng Situatioun wéi mir e Service op Yii 1 geholl hunn a gemierkt hunn datt mir et net weider kënne entwéckelen, well mir sinn aus Entwéckler ausgaang, déi gutt op Yii 1 schreiwen kënnen. All Entwéckler schreiwen gutt op Symfony XNUMX. Wat kann een maachen? Mir hunn Zäit zougewisen, en Team zougewisen, e Manager zougewisen, de Projet nei geschriwwen an de Traffic glat drop gewiesselt.
Duerno kann den alen Service geläscht ginn. Dëst ass meng LiiblingsProzedur, wann Dir e Service aus dem Konfiguratiounsmanagementsystem muss huelen a botzen an dann duerchgoën a kucken datt all d'Autoen an der Produktioun behënnert sinn, sou datt d'Entwéckler keng Spure méi hunn. De Repository bleift am Git.
Dëst ass alles iwwer wou ech wollt schwätzen, ech si prett ze diskutéieren, d'Thema ass holivar, vill hunn dra geschwommen.
D'Rutschen hunn gesot datt Dir Sproochen vereenegt. E Beispill war d'Gréisst vun de Biller. Ass et wierklech néideg et strikt op eng Sprooch ze limitéieren? Well d'Gréisst vum Bild an PHP, gutt, kéint tatsächlech a Golang gemaach ginn.
Tatsächlech ass et fakultativ, wéi all Praktiken. Vläicht, an e puer Fäll, ass et souguer onerwënscht. Awer Dir musst verstoen datt wann Dir en techneschen Departement an enger Firma vu 50 Leit hutt, 45 vun hinnen PHP Spezialisten sinn, aner 3 sinn Devops déi Python, Ansible, Puppet an sou eppes kennen, an nëmmen ee vun hinnen schreift an e puer Zort Sprooch e puer Go Bild änneren Service, dann wann et Blieder, der Expertise mat et. A gläichzäiteg musst Dir no engem Maartspezifesche Entwéckler sichen, deen dës Sprooch kennt, besonnesch wann et seelen ass. Dat heescht, aus organisatorescher Siicht ass dat problematesch. Vun enger Devops Siicht, musst Dir net nëmmen e fäerdege Set vu Playbooks klonen, déi Dir benotzt fir Servicer z'installéieren, awer Dir musst se nach eng Kéier schreiwen.
Mir bauen de Moment e Service op Node.js, an dëst wäert just eng Plattform sinn an der Géigend fir all Entwéckler mat enger separater Sprooch. Mee mir souzen a geduecht, datt d'Spill d'Käerz wäert. Dat ass, dëst ass eng Fro fir Iech ze sëtzen an ze denken.
Wéi iwwerwaacht Dir Är Servicer? Wéi sammelt a kontrolléiert Dir Logbicher?
Mir sammelen Logbicher an Elasticsearch a setzen se an Kibana, an ofhängeg ob et Produktiouns- oder Testëmfeld ass, gi verschidde Sammler do benotzt. Iergendwou Lumberjack, soss anzwousch soss eppes, ech erënnere mech net. An et sinn nach e puer Plazen a bestëmmte Servicer, wou mir Telegraf installéieren an soss anzwousch getrennt schéissen.
Wéi liewen mat Puppet an Ansible am selwechten Ëmfeld?
Tatsächlech hu mir elo zwee Ëmfeld, eng ass Puppet, déi aner ass Ansible. Mir schaffen fir se ze hybridiséieren. Ansible ass e gudde Kader fir den initialen Setup, Puppet ass e schlechte Kader fir den initialen Setup well et praktesch Aarbecht direkt op der Plattform erfuerdert, a Puppet suergt fir d'Konfiguratiounskonvergenz. Dëst bedeit datt d'Plattform sech an engem aktuellen Zoustand hält, a fir datt d'ansibiliséiert Maschinn um neiste Stand bleift, musst Dir d'Spillbicher ëmmer mat e puer Frequenz lafen. Dat ass den Ënnerscheed.
Wéi behalen Dir Kompatibilitéit? Hutt Dir Configuratioun souwuel an Ansible wéi och an Puppet?
Dëst ass eise grousse Péng, mir halen d'Kompatibilitéit mat eisen Hänn an denken un wéi mir vun all deem iergendwou elo weidergoen. Et stellt sech eraus datt Puppet Packagen ausrullt an e puer Linken do ënnerhält, an Ansible, zum Beispill, rullt de Code eraus an passt déi lescht Applikatiounskonfiguratiounen do un.
D'Presentatioun war iwwer verschidde Versioune vu Ruby. Wéi eng Léisung?
Mir hunn dat op enger Plaz begéint, a mir mussen et déi ganzen Zäit am Kapp halen. Mir hunn einfach den Deel ausgeschalt, deen um Ruby leeft, deen mat den Uwendungen inkompatibel war an et getrennt behalen.
Dëst Joer d'Konferenz wäert de 7. Dezember zu Technopolis stattfannen. Mir akzeptéieren Uwendungen fir Berichter bis den 11. November. eis wann Dir wëllt schwätzen.
Umeldung fir Participanten ass op, maach mat!
Source: will.com