Ex scriptoribus ad nostrum suggestum: quomodo progressionem CIAN automated

In RIT 2019, collega noster Alexander Korotkov factus est fama de automation of development at CIAN: ad simpliciorem vitam et opus, nostro Integro suggestu utimur. Vita cycli officiorum indagat, tincidunt exercitationis operationum levat et signanter numerum minorum in productione minuit. In hoc poste, famam Alexandri complebimus et narrabimus tibi quomodo ex simplicibus scriptis venimus ad colligendas res apertas per nostrum suum suggestum, et quid nostra separatio automatio quadrigis facit.
 

Nulla level

"Nulla res talis in gradu nulla est, tale nescio"
Magister Shifu ex pellicula "Kung Fu Panda"

Automatio apud CIAN incepit quattuordecim annos postquam societas condita est. Eo tempore 14 homines in quadrigis evolutionis erant. Credibile, vox? Utique, automatio in aliqua forma exstitit, sed directionem separatam ad integrationem continuam et in codice traditionis anno MMXV figurari coepit. 

Illo tempore ingens monolith Pythonis, C# et PHP habuimus, ministrantes Linux/Fenestras instruentes. Ad hoc monstrum explicandum, copia scriptorum habuimus quae manually cucurrimus. Fuit etiam conventus monolithorum, qui dolorem et dolorem ob conflictationes induxit cum ramis bus, defectibus emendatis, et "aliud munerum in aedificio" instaurando. Simplicior processus vidi sic:

Hoc laetus non eramus et iterabilem, automatum et tractabilem aedificandi et instruere processum aedificare voluimus. Ad hoc systema CI/CD opus erat et inter liberam versionem Teamcity et liberam versionem Jenkins elegit, quoniam cum eis laboravimus et nos ambos ad munera statuta aptamus. Elegimus Teamcity ut productum recentioris. Tunc temporis architecturae microservices nondum usi eramus et magnum numerum operum et inceptorum non exspectavimus.

Venimus ad notionem systematis nostri

Exsecutio Teamcity sola pars operis manualis tollitur: restat creatio Petitionum Pull, quaestiones promovendas in Jira statu, et quaestiones delectu ad emissionem. Systema Teamcity diutius hoc obire non potuit. Iter eligere necesse fuit ulterioris automationis. Bene consideravimus operandi cum scriptoribus in Teamcity vel commutatione ad systemata tertia partium automationis. Sed tandem decrevimus nos maximam flexibilitatem indigere, quam sola nostra solutio praebere potest. Ita apparuit prima versio automationis internae systematis Integro appellatum.

Teamcity automatio agit in gradu deductionis aedificandi et instruere processuum, dum Integro in summo gradu automationis evolutionis processuum tendit. Necesse erat ut opus coniungi cum quaestionibus in Jira cum processu fonte coniungendi codicem in Bitbucket. In hac scaena, Integro laboratorium suum habere coepit ad operandum diversorum generum opera. 

Ob auctam automationem in processibus negotii, numerus inceptorum ac currit in Teamcity aucta. Accessit igitur nova quaestio: una instantia gratis Teamcity non satis (3 agentibus et 100 inceptis), aliam instantiam (3 plura agentia et 100 incepta addimus), deinde aliam. Quam ob rem cum systemate plurium fasciculorum confecti sumus, quod difficile erat administrare;

Cum quaestio de 4 instantiae causa orta est, intelleximus nos sic vivere non posse, quia totae sumptus 4 instantiarum sustinendi intra fines nullos erant amplius. Quaesitum est de acquirendo Teamcity solvenda vel eligendo libera Jenkins. Calculationes in instantiis et automationibus fecimus et decrevimus nos in Jenkins vivere. Post aliquot hebdomades, Jenkins mutavimus et quaedam capitis capitis consortia removevimus cum exemplis multiplicibus Teamcity conservandis. Ergo potuimus intendere in evolvendo Integro et Jenkins nobismetipsos customisando.

Cum incremento fundamentalium automationis (forma latae creationis Pull Requests, collectionis et publicationis Codicis coverage et aliorum schedularum), vehemens est cupiditas ut quam maxime manuales emissiones deserant et hoc opus robotis praebeant. Praeterea societas incepit movere ad microservices in societate, quae frequentes emissiones requirebant, et separatim ab invicem. Hoc modo sensim pervenimus ad solutiones automaticorum nostrorum microserviorum (nunc monolitum manually propter multiplicitatem processus dimittimus). Sed, ut fieri solet, nova multiplicitas orta est. 

Testis automate sumus

Ob automationem emissionum processuum evolutionis acceleraverunt, partim ob aliquas probationes omissiones. Et hoc ad temporalem dispendium qualitatis. Leve sonat, sed una cum acceleratione emissionum, necesse fuit productum progressionem methodi mutare. Oportuit cogitare de automatione probationis, responsabilitatis personalis insinuationis (hic loquimur de "ideo accipiendi in capite", non multas pecuniarias) de elit ad codicem emissi et cimices in eo, necnon ad decisionem. dimittis/non dimittis negotium per instruere latae sententiae. 

Quaestionum qualitatem subtrahentes, ad duas magnas decisiones venimus: canarias probationes gerere coepimus et automatariam vigilantiam erroris in background cum responsione latis ad eius excessum introducimus. Prima solutio effecit ut manifestos errores inveniret antequam codicem ad productionem plene emitteretur, secunda responsionis tempus ad problemata in productione reduxit. Errata quidem fiunt, sed maximam partem temporis et laboris nostri non corrigendo, sed extenuando expendimus. 

Automation Team

Nos aute baculum 130 tincidunt habemus et pergimus crescere. Continua integratio et code traditio quadrigis (infra postea ad Deploy et Integrationem seu DI team) constat ex 7 hominibus et operibus in 2 directionibus: progressionem Integro automationis suggestu et DevOps. 

DevOps responsabilis est pro ambitu Dev/Betae CIAN situs, Integro ambitu, tincidunt quaestiones solvendas adiuvat et novos aditus ad ambitus scalas evolvit. Directio Integro evolutionis agit de ipso Integro et de officiis affinibus, exempli gratia, plugins pro Jenkins, Jira, Confluentia, et etiam utilitates auxiliares et applicationes ad iunctiones evolutionis auget. 

Di turma collaborative cum rostris operantur, quae architecturae, bibliothecae, progressionis enucleatur, interne appropinquat. Eodem tempore, quaevis elit intra CIAN ad automationem conferre potest, exempli gratia, micro-automationem facere ut necessitati teamum conveniat vel notionem frigidam communicet quam ad automationem meliorem efficiendam.

Libum accumsan automation at CIAN

Omnes systematis automationis involuti in plures ordines possunt dividi:

1. Systemata externa (Jira, Bitbucket, etc.). Partes progressionis laborant cum illis.
2. Integer sed diam. Saepissime tincidunt non operantur directe, sed id quod custodit omnes cursus automation.
3. Partus, orchestrationis et inventionis officia (exempli gratia Jeknins, Consul, Nomad). Eorum adiutorio codicem ministrantibus explicamus et ut officia inter se laborent.
4. Corporalis tabula (servatores, OS, programmata affinis). Codex noster in hoc gradu operatur. Hoc vel corporis cultor vel virtualis esse potest (LXC, KVM, Docker).

Secundum hanc notionem, areas intra DI turmas officiorum dividemus. Primi duo gradus in regione responsabilitatis Integro progressionis directae sunt, et duo ultimi gradus iam sunt in ambitu responsabilitatis DevOps. Haec separatio nos sinit intendere in opera et commercium non impedit, quoniam propinqui sumus inter nos et scientiam et experientiam perpetuo commutamus.

Integer semper

Dolor sit amet in Integro et incipere technicae acervus:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (senex Integro monolitus in Java 8 remanebit)
• Ver Booz 2.X + Ver Cloud Mando
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (embedded)
• Grafana + Graphite Prometheus + Jaeger + ELK
• Web UI: React (CSR) + MobX
• SSO: Keycloak

Principio microserviae evolutionis adhaeremus, quamquam legatum habemus in forma monolithi primae versionis Integri. Quaelibet microservio in suo Docker continente decurrit, et officia inter se communicant per petitiones HTTP et nuntiis RabbitMQ. Microservices se per Consulem se invenire et id petere, licentia per SSO transeuntes (Keycloak, OAuth 2/OpenID Connect).

Ut exemplum reale-vitae, cum Jenkins mutuo commercium considera, qui ex sequentibus gradibus consistit:

1. Procuratio workflow pro microservice (infra post microservice ut Fluxus citata) aedificatum in Jenkins currere vult. Ad hoc consulem utitur ut IP:PORTUM microservii ad integrationem cum Jenkins (infra ad microserviam Jenkins referendam) inveniendam, asynchronam rogatum mittit ut in Jenkins aedificandi initium faciat.
2. Accepta petitione, Jenkins microservice generare et respondet cum ID Iob, quod tunc adhiberi potest ad exitum operis cognoscendum. Eodem tempore in Jenkins via a CETERA API nomen trigger aedificandi.
3. Jenkins aedificandum fungitur et, post peractam, telam cum effectibus ad microserviam Jenkins mittit.
4. Jenkins microservice, accepto interretiali, nuntium generat de processu petitionis complemento, eique eventus adiungit exsecutioni. Generatum nuntium ad RabbitMQ queue mittitur.
5. Per RabbitMQ, nuntius divulgatus perveniat ad minimum operae fluxum, qui discit eventum suum negotium expediendi, adaptando Job ID ex petitione et nuntio accepto.

Nunc habemus circiter 30 microservices, quae in plures circulos dividi possunt;

1. Configurationis administratio.
2. Informationes et commercium cum usoribus (nuntii, mail).
3. Fons operandi cum codice.
4. Integratio cum instrumentis instruere (jenkins, nomad, consul, etc.).
5. Cras (dimittit, errores, &c.).
6. Interreti utilitas (UI ad culturas administrandas, statisticas colligendas, etc.).
7. Integratio cum elaboratis elit et similibus systematibus.
8. Procuratio workflow pro diversis operibus.

Workflow tasks

Integra automata actiones ad negotium lifecycli pertinentes. In simplicioribus terminis, vita cycli operis intellegetur ut laboris cursus in Jira. Progressus noster progressiones varias variationes laboratorum secundum inceptum, genus operis et optionum in particulari munere delecti. 

Intueamur workflow quem frequentius utimur;

In schemate, calces indicat transitum ab Integro automatice vocari, dum figura humana indicat transitum ab homine manually vocari. Plures vias inspiciamus quas in hoc workflowe munus capere potest.

Omnino manualis probatio in DEV+BETA sine probationibus canariis (hoc fere est quomodo monolitum dimittimus);

Alia transitus potest esse accumsan. Interdum via quam exitus capiet per optiones in Jira seligi potest.

negotium motus

Intueamur gressus principales qui peraguntur cum negotium per "DEV Testis + Canariae Testium" workflow movens:

1. In elit vel PM negotium creat.

2. In elit negotium ad laborem sumit. Post completionem, status permutat in REVIEW.

3. Jira Webhook ad Jira microservice mittit (responsabilis pro integratione cum Jira).

4. Jira microservice rogatu mittit ad servitium Flow (responsabile pro internis workflus in quo opus exercetur) ut workflow committitur.

5. Intra fluunt servitium:

• Recognitores munus assignati sunt (Microserviae Users qui omnia sciunt de utentibus + Jira microserviis).
• Per Microservium fontem (novit de repositoriis et ramis, sed cum ipso codice non laborat), quaesitio facta est repositoria quae ramum proventus nostri continent (ad simpliciorem inquisitionem, nomen rami cum eventu coincidit. numerus in Jira). Saepissime munus unum tantum ramum habet in repositorio, haec simplificat administrationem instruere queue et connexionem inter repositoria reducere.
• Uterque ramus inventus est, actus sequens perficitur;

  i) Ramum magistri adaequationis (Git microservice ad operandum cum codice).
  n) Ramus obstruetur a mutationibus e elit (Microservice Bitbucket).
  III) Rationem ad hunc ramum trahendum creatum est (Bitbucket microservice).
  IV) Nuntium de novo libellorum rogatio ad sermones elit (Notify microservice for working with notifications).
  v) Aedificare, probare et disponere negotia incipiunt in DEV (Jenkins microservice ad operandum cum Jenkins).
  vi) Si omnes gradus superiores feliciter perficiuntur, Integro eius Approbatio in Pull Request (Microservice Bitbucket).

• Integrum manet Approba in Pull Request ab designatis Recognitoribus.
• Cum primum omnes probationes necessariae receptae sunt (including probationes automated positive transierunt), Integro negotium transfert statum testandi in Dev (Jira microservice)

6. Tester negotium probate. Si quaestiones nullae sunt, negotium ad Promptum Status Aedificandi transfertur.

7. Integro "videt" munus ad emissionem paratum esse et incipit instruere in modo canario (Jenkins microservice). Prompta ad remissionem per regulas statuta determinatur. Exempli gratia, munus est in statu debiti, nullae sunt in aliis seris operibus, nunc non sunt activae impositiones huius microservici, etc.

8. Munus transfertur in statum Canarium (Jira microservice).

9. Jenkins munus instruere per Nomad in canariis (plerumque 1-3 instantiis) notificat emissionem servitutis vigilantiae (Microserviae DeployWatch) de instruere.

10. DeployWatch microservices curricula errorum colligit et ad illud, si opus est, reflectit. Si background error exceditur (forma curriculi norma automatice computatur), tincidunt notificantur per microserviam Notify. Si post 5 minutas elit non responderit (click Revert or Stay), tunc latis regressus instantiarum canariae educitur. Si curriculum non exceditur, elit tum munus instruere ad productionem manuale debet (strepitando per bullam in UI). Si intra 60 minutas elit, instruere ad productionem non emisit, instantiae canariae etiam revolventur propter rationes securitatis.

11. deductis instruere ad productionem;

• Negotium ad productionem status transfertur (Jira microservice).
• Jenkins microservice incipit processum instruere et microservire DeployWatch notificat de instruere.
• DeployWatch microservice coercet quod omnia vasa in productione renovata sunt (caves erant quando non omnia renovata sunt).
• Per Microservice certiorem facere, notificatio circa eventus instruere ad productionem mittitur.

12. Creatores 30 minutas habebunt ut munus e productione revolvere incipiant, si mores microservii falsa detegantur. Post hoc tempus, negotium automatice in dominum mergetur (Git microservice).

13. Post felicem in dominum mergetur, negotium status ad Clausum mutabitur (Jira microservice).

Tabula non simulas plene explicari (re vera etiam plures gradus sunt), sed gradum integrationis in processibus aestimare permittit. Hanc rationem idealem non consideramus et meliores processus emissiones emissiones et subsidia instruere debemus.

deinde quid

Magna consilia habemus ad automationis evolutionem, exempli gratia, operationes manuales eliminando per monolitum emissiones, vigilantia in programmate automatico emendando, et commercium cum tincidunt emendando.

Sed hic jam desinamus. Multa argumenta in automation recognitionis superficialiter contexuimus, quaedam omnino non tacta sunt, sic ad interrogata respondere laeti erimus. Exspectamus suggestiones de quid singula operiant, scribe in comment.

Source: www.habr.com