jurchiks Posted April 24, 2016 Report Share Posted April 24, 2016 That's the spirit :D Quote Link to comment Share on other sites More sharing options...
briedis Posted April 24, 2016 Author Report Share Posted April 24, 2016 Ellē ratā visu automatizāciju, nafig vispār pieņemti standarti! Jurčiks visu labāk zina :) Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 24, 2016 Report Share Posted April 24, 2016 Ellē ratā visu automatizāciju, nafig vispār pieņemti standarti! Jurčiks visu labāk zina :) Pievienojos qwerty, ja nav grūti, moš pastāsti kā jums būvējas? Moš es ar saņemšos sarakstīt, kas un kā. Quote Link to comment Share on other sites More sharing options...
briedis Posted April 24, 2016 Author Report Share Posted April 24, 2016 Pievienojos qwerty, ja nav grūti, moš pastāsti kā jums būvējas? Moš es ar saņemšos sarakstīt, kas un kā. Diemžēl neko tādu stilīgu nedarām. Ir mums savs gitlabs, ir arī CI pieslēgts viņam, vienreiz pat palaidu buildu vienam savam projektam, bet tā arī tas palika. Ir kaut kādu custom risinājumi, kas kaut kādā mērā pārbauda kodu, bet nekas vairāk. Printful (ir vakances: https://www.theprintful.com/darbs)plānojam šovasar mēģināt ieviest testēšanu vismaz kaut kādā basic līmenī ar Codeception. Flows projektiem pārsvarā ir caur master, kas ir produkcija, dienā neskaitāmas reizes relīzojam, paši arī testējam. Ja kodējamas lielākas lietas, tad taisa savus brančus. Ja kas nopietnāks, tad palaižam caur merge rekvestiem. Arl ielajiem projektiem problēma, ka tie tik ļoti iesakņojušies, ka viņus izcelt un izolēt ir diezgan nereāli, lai palaistu uz kāda CI. Quote Link to comment Share on other sites More sharing options...
jurchiks Posted April 24, 2016 Report Share Posted April 24, 2016 Karoče incoming flame no F3llony in 3... 2... 1... Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 24, 2016 Report Share Posted April 24, 2016 (edited) Mums viss stāv uz Bitbucket. Visas iekšējās bibliotēkas (kas pamatā ir Symfony bundles) atrodas atsevišķās repozitorijās (uz doto brīdi tikai manā konkrētajā projektā ir pie 80 repozitorijām). Tā pat, kā projektiem, arī libām ir savi build procesi, kas pēc katra merge izlaiž jaunu versiju - automātiski. Par build un testu automatizāciju rūpējas Jenkins. Jenkins uzdevumi tiek automātiski ģenerēti no JJB konfigurācijas - kas cita starpā tiek pieglabāta atsevišķā repā, kas weirdly enough ar POST hūku pārģenerē visus Jenkins uzdevumus pēc tam, kad konfigurācija tiek pamainīta. Katram projektam/bibliotēkai gandrīz vienmēr ir 2 veidu testi - TDD specs (PHPSpec) un integrācijas testi (PHPUnit). Visas bibliotēkas seko pamatā vienai un tai pašai struktūrai, so pamatā ieviest jaunu šārējamu bundli prasa to vien kā pievienot jaunu repozitoriju un pāris rindas JJB. Visas versijas bibliotēkām pēc builda tiek pieglabātas arī Satis - tā sanāk ātrāk deploymenti, jo nav jaklonē no GIT + backup ja bitbucket nofeilo, buildi tapat darbojas sava nodabā. Deploy pamatā notiek izmantojot Capistrano (ir daži mazāki projekti ar Mina vai Deployer) - artefakti tiek sabūvēti lokāli un pēc tam izmesti attiecīgajā vidē. Pagaidām neprasās pēc CI artefaktiem - vidējais laiks pilnam produkcijas deploy atkarībā no projekta ir pārdesmit sekundes līdz 5 minūtes. Normālām mazizmēra izmaiņām, neskaitot code review un manuālu feature un acceptance testēšanu, viss cikls aizņem varbūt 10 minūtes. Deploy daudzums ir "cik vien gribi". Citas dienas ir 1,2 produkcijas relīzes, citas ir 10. Emergency deploy - ir tiešā ķēde uz master un deploy, pāris minūtes. Code review parasti veic protams pats autors un minimums 2 citi developeri, un ne obligāti no viena un tā paša projekta vai pat offisa - tas darās tāpēc, lai visi kantorī būtu +/- kursā par to, kas apkārt notiek. Visas izmaiņas un darbības pret produkcijas datubāzēm prasa vismaz vēl 1 cilvēka signoff - tajā skaitā, visi queries, kas neietilpst migrācijās (tiek smagi lietots pt-online-schema-change, ir daudz grandiozi masīvu tabulu). Izstrāde notiek apmēram šādi - vienmēr branch out no master uz atsevišķu branchu (ja liela izmaiņa un vairāki devi piedalās - feature branch, un tad papildus branchi). Ir divi mainstream branchi, master/production un integrācijas branch. Viss, kas atrodas master = produkcija, viss, kas atrodas integrācijā - ir integrācijas serveros. Ir arī development serveri, kur var manuāli izmest izmaiņas kas prasa vairāk testu, 3rd party signoff utt. Visas vides ir mirori no produkcijas. Integrācija tiek ļoti bieži uzpildīta ar pilnu produkcijas datu backup, parasti no tās pašas dienas. Pull requesti tiek veidoti pret integrāciju, tā pat kā merge. Pēc integrācijas merge notestē integrācijas serveros, izveido relīzi un tiek nodeployots uz produkciju. Visi testi tiek izpildīti Jenkins 3 reizes: 1. pirms merge integrācijā 2. pēc merge integrācijā ar automātisku deploy uz integrācijas serveriem 3. pēc relīzes uz master un pirms deploy. Testi tiek darbināti Docker vidē, kas ir maksimāli tuva produkcijai (pamatā, 100% klons), lokāli izstrāde arī notiek Docker vidē. Gan vieglāk saturēt dependencies, gan vieglāk jauniem cilvēkiem tikt klāt pie reālas izstrādes - initial setup aizņem pāris stundas, no kurām lielākā daļa aizņem lejupielādēt docker images un noklonēt projektu repas :P nekas no valodām un runtaimiem lokāli nav jāinstalē. Produkcijā viss griežas virtuālmašīnu fermās, konfigurāciju menedžē Puppet. Logus visas aplikācijas raksta dubultā - syslog un rotētos failos, syslog logus reportē uz centrālo Ellastic serveri, kam piekabināta Kibana un Elastalert - Kibana un Jenkins build statusi arī smuki uz ekrāna pie sienas tiek attēloti, pametot aci vienmēr zini vai nav kāda šaize. Pēc deploy Kibana var paskatīties, vai nav izmaiņas trafika plūsmā, utt. metrikās. Visu infrastruktūru monitorē Nagios un kaudze dažādu citu sistēmu - tiek monitorēts viss no response time, beidzot ar mongo opcounters. Bez šīm ir vēl daudz dažādu sistēmu, citi projekti, utt. utjp. Piemēram, android/ios aplikācijām flows nedaudz atšķiras, utt. utjp. Bet web side pamatā notiek šādi. Gan jau kaut ko piemirsu still... Karoče incoming flame no F3llony in 3... 2... 1... Jo? Tikai tāpēc, ka tev tā gribētos? :D Edited April 24, 2016 by F3llony Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted April 25, 2016 Report Share Posted April 25, 2016 Labs apraksts, really advanced tas viss. Tas jūs paši līdz tam nonācāt, vai tas ir tāds kā tipisks risinājums web projektiem, kas tā kā mazliet palielāki? Kā izstrādātāji jūtas, nesanāk liels overheads? Un ko nozīmē deploymenti vairākas reizes dienā? Frontendā es saprotu - podziņa tur vai šurp, bet backendā.. Nu vispār arī saprotu, tiek kaut kas uztaisīts un pēc relīzošanas jau kādu laiku šis tas jāpamaina. Darba laiks - pats par sevi, diezgan brīvs. Esmu baigā pūce, man 9-17 neder. Un kā tas sanāk, kādas ir iespējas? Jo esmu arī mega pūce. Nav problēmu piecelties arī 6os, bet es nespēju domāt no rītiem. Jau no pirmajām klasēm visu patiesībā mācījos vakaros, pildot mājasdarbus, man ilgi nepieleca, ka citi skolēni mācās arī stundu laikā. Nezinu, varbūt ar ķīmiju kaut kas saistīts. Tagad arī, ja no rīta esmu uzcēlies, varu darboties, bet ne jau sēžot pie datora, to fiziski nespēju. :D (ar fiziski es domāju tiešām fiziski. Vakaros nav problēmu - varu kaut līdz rītausmai nosēdēt nepieceļoties.) Quote Link to comment Share on other sites More sharing options...
jurchiks Posted April 25, 2016 Report Share Posted April 25, 2016 (edited) ...viss tas garais penteris... Nu vot tas ir reāli complicated stuff. Man tādas lietas nepatīk. Jo? Tikai tāpēc, ka tev tā gribētos? :D Tikai tāpēc, ka that's just what you do. Un kā tas sanāk, kādas ir iespējas? Nu tagad strādāju lielākoties no mājām un uz ofisu aizeju tikai 1-2 dienas nedēļā, un arī tad tikai uz kādām 4h. Strādāju vēlu, pagājušonedēļ gandrīz katru dienu līdz kādiem trijiem rītā. Bet es nestrādāju non-stop 8h+ no vietas, es pa 2-3h un tad kaut ko citu padaru - kaut ko paskatos, palasu netā, paspēlēju kādu spēli, paēdu, aizeju uz veikalu, vai kādu pasākumu, meetupu... Par iespējām - kā minēju, pirms izvēlējos šo darba vietu, bija 2 superīgas intervijas, vienā no tām piedāvāja strādāt pilnībā no mājām (viņiem nemaz ofisa nebija, draugu grupa, kas katrs māk daļu no kopējā, un tad ņemas). Neizvēlējos tāpēc, ka piedāvāja tikai 700€ neto, gan uz pusslodzi, bet man vajag uzpildīt bikīt krājkasīti nebaltām dienām. Škrobe vienīgi, ka tur piedāvāja darboties tikai ar OctoberCMS... Ar WP nesalīdzināt. Pagātnē bija tā, ka otrajā IT darba vietā kopā nostrādāju ~2 gadus, pirmo gadu full-time ofisā, otro gadu full-time no mājām. Pēc tam nākamajā darbā 1 gadu un 3 mēnešus full-time no mājām. Tad bija Dyninno un viens 2 nedēļu aplauziens, tagad ir šis darbs. Visur, kur strādāju no mājām, cēlos savā laikā. Edited April 25, 2016 by jurchiks Quote Link to comment Share on other sites More sharing options...
jurgenzz Posted April 25, 2016 Report Share Posted April 25, 2016 (edited) Kas Latvijā būs tās lielās (100+ devi) un labās kompānijas? Edited April 25, 2016 by jurgenz Quote Link to comment Share on other sites More sharing options...
qwerty Posted April 25, 2016 Report Share Posted April 25, 2016 jurchik, ja nav noslēpums, kā mainījās atalgojums atkarībā no ofisa/mājām? Quote Link to comment Share on other sites More sharing options...
e-remit Posted April 25, 2016 Report Share Posted April 25, 2016 Kas Latvijā būs tās lielās (100+ devi) un labās kompānijas? Par "labās" būs gaumes lieta, kā arī veiksme, kurā projektā nonāksi. Bet "lielās" jau it kā ir vairākas, ne visur gan ir PHP, bet citās var atrast JS, Ruby, Python, ja vien tevi neinteresē .NET, Java vai Oracle. PHP noteikti ir Draugiem grupā. Ne-PHP var atrast: https://www.accenture.com/ph-en/careers/jobsearch http://www.exigenservices.lv/job/vakances https://www.tieto.lv/karjera/vakances?field_jobs_location[0]=11756 http://ctco.lv/careers/vacancies/ Vari vienkārši aizsūtīt savu CV, tad lai paši skatās - uzaicinās tevi vai nē. Tiesa, lielajam kompānijām ir niķis atbildēt pat pusotra mēneša laikā, sevišķi vasaras atvaļinājumu laikā. Quote Link to comment Share on other sites More sharing options...
jurgenzz Posted April 25, 2016 Report Share Posted April 25, 2016 ok, viena no tām ko nosauci, mani jau pasauca pie sevis, interesēja vai ir laba :D Quote Link to comment Share on other sites More sharing options...
Wuu Posted April 25, 2016 Report Share Posted April 25, 2016 Neviens kā freelancer startapos nav mēģinājis? Man jau liekas, ka tādos projektos ar prieku var strādāt. Quote Link to comment Share on other sites More sharing options...
e-remit Posted April 25, 2016 Report Share Posted April 25, 2016 Neviens kā freelancer startapos nav mēģinājis? Man jau liekas, ka tādos projektos ar prieku var strādāt. Kāpēc freelancer? Startupos, parasti, vajag cilvēkus, kas līdz ausīm ir tajā projektā. Lai tādā strādātu ar prieku, tev no sākuma jānotic vadītājam. Pirmkārt, vadītājam jābūt tādam, kurš deg par savu projektu, pārzina savu jomu, sagādā finanses un interesējas, kā tu ātrāk visu vari uztaisīt. Otrā svarīgā lieta, kas jānoskaidro, no kurienes viņam finanses un uz cik ilgu laiku. Ja tev pasaka: "Par finansēm neuztraucies!", tad tā ir slikta zīme. Painteresējies, kā viņš ir nodrošinājies pret pēkšņu investora atteikšanos no turpmākas sadarbības! Esmu redzējis, kā tas izskatās, kur viens projekts tā arī nogrima, jo investoram kaut kas neiepatikās, kaut gan solītais gads vēl nebija pagājis, cits projekts sarūpēja visiem bezalgas atvaļinājumu no nākamās nedēļas, no kura ne jau visi atgriezās. Quote Link to comment Share on other sites More sharing options...
F3llony Posted April 25, 2016 Report Share Posted April 25, 2016 Labs apraksts, really advanced tas viss. Tas jūs paši līdz tam nonācāt, vai tas ir tāds kā tipisks risinājums web projektiem, kas tā kā mazliet palielāki? Kā izstrādātāji jūtas, nesanāk liels overheads? Un ko nozīmē deploymenti vairākas reizes dienā? Frontendā es saprotu - podziņa tur vai šurp, bet backendā.. Nu vispār arī saprotu, tiek kaut kas uztaisīts un pēc relīzošanas jau kādu laiku šis tas jāpamaina. Un kā tas sanāk, kādas ir iespējas? Jo esmu arī mega pūce. Nav problēmu piecelties arī 6os, bet es nespēju domāt no rītiem. Jau no pirmajām klasēm visu patiesībā mācījos vakaros, pildot mājasdarbus, man ilgi nepieleca, ka citi skolēni mācās arī stundu laikā. Nezinu, varbūt ar ķīmiju kaut kas saistīts. Tagad arī, ja no rīta esmu uzcēlies, varu darboties, bet ne jau sēžot pie datora, to fiziski nespēju. :D (ar fiziski es domāju tiešām fiziski. Vakaros nav problēmu - varu kaut līdz rītausmai nosēdēt nepieceļoties.) Semi-tipisks. Cik ar citiem komunicēju, zinu, ka ja ne vienmēr lietotas tās pašas tehnoloģijas, tad risinājumi ir ļoti līdzīgi, taču es nevarētu teikt, ka visi kaut ko tādu dara - personiskais iespaids ir drīzāk nē. Konkrēti Ebay/Magento, Skyscanner, AirBNB ir diezgan līdzīga kalibra sistēmas. Overheads developeriem pamatā nav nekāds - tiem, kas tikai programmē ir tikai branch-out/pullrequest-in un tikai skaties kad pullrequestā parādas komentāri no CI - build pass, build fail. Lokāli docker komandas ir enkapsulētas bash.rc skriptos, kas pievieno ap duci shortkutu, visiem nepieciešamajiem darbiem no php cli līdz npm install. Ja godīgi, tīri devam darboties ir ļoti, ļoti ērti - viss jauki aprakstīts, viss labi dokumentēts. Relīzes vairākas reizes dienā ir tāpēc, ka nepārtraukti tiek veikti uzlabojumi un izmaiņas, ir full-agile scrum, ir backlogs, kurā vienmēr ir kaut kas ko darīt, un darbi tiek pēc iespējas dalīti ļoti mazos gabaliņos, lai developerim nenāktos sēdēt nedēļām pie viena grandioza taska. Līdz ar to, 10 mazas izmaiņas dienā un 10 relīzes ir okei dīls. Parasti nav tik daudz, bet reizēm notiek. Patiesībā developeri ir diezgan priecīgi par šādu setupu, pie mums ir braukuši citi start-un-nestartapi skatīties, un vice versa, vienkārši atrādot un atstāstot, kā strādājam un skatīties ko dara citi. Kaut vai piemēra pēc, tie paši test buildi - ir 3 leveli kuros izķert kļūdas, code review un vēl manuāla testēšana. Dienas beigās sausais atlikums ir, ka produkcijā nopietnas kļūdas nonāk ļoti, ļoti reti. Pēdējo reizi ko atceros, bija pāris mēnešus atpakaļ, un arī tad problēma bija jauna veida statistikas datu pieglabāšana, ko no sākuma varēja vienkārši atmest un sākt glabāt pareizi, pa jaunam. Tas viss dod deviem tādu kā drošības sajūtu, mazina stresu. Viss, kas ir sabūvēts ir paradzēts tieši tam lai atvieglotu developeriem darbu un noņemtu nost visu noise un uztraukumus par infrastruktūru un ko tik vēl ne. Par tavu pūces problēmu, man ir līdzīga. Te vari ierasties jebkurā laikā starp 9 un 11, prom ej no 18-20, visi rēķinas, ka mītingi utt notiek periodā no 11-18. Nav nekas jāpiesaka vai jāsaskaņo. Gribi nāc 9, gribi nāc 11. Vasarās piektdienas pēcpusdiena pēc 14 brīva. Nu vot tas ir reāli complicated stuff. Man tādas lietas nepatīk. Tādā gadījumā man Tev ir sliktas ziņas par Tavu profesijas izvēli. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.