Trainul de lansări Salesforce: O abordare practică a managementului versiunilor

Managementul versiunilor, așa cum sugerează și numele, este procesul de gestionare, planificare, programare și control al unei build de software prin diferite etape și medii; inclusiv testarea și implementarea versiunilor de software (Humble & Farley, 2011).

Este un subiect destul de mare în sine și poate fi perfecționat doar în timp încercând diferite iterații cu echipele de dezvoltare și potrivirea nevoilor de afaceri sau lansărilor de caracteristici. Vom încerca să acoperim practicile din industrie de gestionare a metadatelor, construirea CI și managementul sandbox pentru gestionarea trenului de lansare a unei organizații .

Dar ce este un tren de eliberare?

Un tren de lansare este o tehnică progresivă și previzibilă de livrare a caracteristicilor. Este necesar ca dezvoltatorul să stabilească un proces formal pentru a prelua orice modificări făcute în mediul de dezvoltare și a le implementa în producție.

Un tren de eliberare poate fi împărțit în linii mari în trei segmente:

• Gestionarea metadatelor
• Construire de integrare continuă
• Gestionare Sandbox

Managementul metadatelor

Metadatele sunt date care oferă informații despre alte date. Salesforce oferă un model de metadate bogat și puternic prin intermediul API-ului său de metadate . Metadatele aplicației dvs. descriu și cuprind un set de metode care oferă acces programatic la codul sursă și configurația organizației dvs.

API-ul Metadate este cea mai bună modalitate de a gestiona personalizările în Salesforce. Acceptă metode de create , read , update și delete . Puteți folosi Change Sets, Force.com IDE și Ant Migration Tool pentru a migra metadatele de la o organizație la alta, deoarece toate oferă migrări prin API.

Fiecare instrument are propriile sale avantaje și există mai multe lucruri de luat în considerare atunci când alegeți unul:

Tabelul 1: Comparația instrumentelor pentru migrarea metadatelor

API-ul Metadata este excelent în a-și îndeplini scopul atunci când dezvoltă și migrează modificări pe platforma Force.com. Dar există o mică problemă - nu toate metadatele Salesforce sunt acceptate de API-ul Metadate. Documentația oficială oferă o listă de componente neacceptate.

Dacă organizația dvs. efectuează modificări care nu sunt acceptate de API-ul Metadate, trebuie să vă asigurați că replicați manual acele modificări în organizația de destinație. Cel mai bun mod de a urmări aceste modificări este o foaie de calcul. Dacă trebuie să recurgeți la această abordare, este întotdeauna recomandabil ca o singură persoană să facă aceste modificări și să le urmărească.

Aceasta ar fi o listă generală bună de coloane pe care le-ar putea folosi pentru urmărirea acestor modificări într-o foaie de calcul:

• Denumirea componentei
• Tip de componentă
• Schimbați proprietarul
• Descrierea funcționalității
• Maparea capacităților
• Dependență de alte componente
• Numele examinat/revizorului
• URL
• Nume/ID organizație
• Alte comentarii

Controlul versiunilor și integrarea continuă

Migrarea modificărilor în producție ar trebui să fie un proces fără probleme, deoarece este doar o repetare a aplicării modificărilor în mediul de testare și punere în scenă. Totuși, există întotdeauna o șansă ca lucrurile să meargă spre sud și atunci ai nevoie de un plan de rezervă. Este foarte important să păstrați copii de siguranță ale metadatelor organizației dvs. și pentru asta sunt controlul versiunilor și construcția CI .

Controlul versiunilor este o necesitate absolută pentru orice organizație. Le permite dezvoltatorilor să lucreze într-un mod colaborativ, eficient și sigur. Gestionarea dezvoltării și migrării codului multi-dezvoltator, multi-sandbox este o provocare în Salesforce. Salesforce are, de asemenea, propriul program pentru lansări și întreținere. Aceste actualizări oferă noi funcții, dar ar putea introduce o modificare în API-ul Metadate, care poate distruge construcția CI. Deci, în afară de situațiile în care dezvoltatorii își suprascriu reciproc modificările, controlul versiunilor vă ajută să construiți o strategie de rollback. A avea o strategie de rollback este o necesitate atunci când aplicația dvs. rulează pe Force.com.

Următoarea diagramă de flux ilustrează o structură practică pentru Controlul versiunii și CI. Vom încerca să vă oferim o descriere rapidă a ceea ce reprezintă diagrama.

1. Un dezvoltator ar verifica modificarea în sistemul de control al versiunilor.
2. CI Server/Jenkins va implementa cea mai recentă versiune în sandbox CI și va rula clase de testare.
3. Dacă implementarea în pasul 2 are succes, atunci modificările sunt îmbinate în ramura QA.
4. CI va implementa apoi cel mai recent commit de la filiala QA în sandbox QA.
5. Dacă QA respinge modificările din cauza eșecurilor testului, pașii de la 1 la 3 ar trebui să fie executați din nou până când QA șterge modificările.
6. După ce modificările trec testarea în QA, modificările sunt îmbinate în ramura Master.
7. Cele mai recente modificări din ramura Master sunt implementate în sandbox-ul Master.

Se poate alege să adauge mai multe filiale în funcție de nevoile organizației. Dar structura de mai sus funcționează bine pentru structurile de dezvoltare la nivel mediu până la întreprindere.

Administrare Sandbox

Pentru a profita la maximum de procesul DevOps al organizației dvs., este foarte important să configurați structura sandbox. Înainte de a ne aprofunda mult în ea, să discutăm despre diferitele tipuri de sandbox-uri pe care ni le oferă Salesforce.

Un sandbox este o copie aproape exactă a metadatelor de producție. Sandbox-urile sunt de obicei folosite pentru dezvoltare, testare, organizare și instruire. Există patru tipuri de cutii cu nisip și ar trebui să acorde o atenție cuvenită atunci când alegeți o cutie cu nisip. Cutiile de nisip Full Copy ar putea costa o mulțime de bani!

Mai jos este tabelul pentru limitele impuse de Salesforce pentru diferite sandbox-uri.

Tabelul 2: Comparația limitelor

Putem vedea că prețul nu este singura diferență între sandbox-uri.

Sandbox-ul pentru dezvoltatori are o perioadă de reîmprospătare de o zi, ceea ce îl face potrivit pentru dezvoltare, dar poate găzdui doar 200 MB de date și nicio dată de producție. Ca opus polar, sandbox-urile de copiere completă au o copie exactă a datelor de producție; chiar și ID-urile de înregistrare sunt aceleași. Acest lucru l-ar putea face grozav pentru testare și punere în scenă, dar perioada de reîmprospătare de 29 de zile face dificilă obținerea celor mai recente metadate și date de producție în sandbox-ul complet pentru copiere.

Tabelul de mai jos acționează ca o regulă generală pentru selectarea sandbox-urilor:

Tabelul 3: Cazuri de utilizare pentru selecția Sandbox

Mai jos este structura tipică a organizației care este adoptată pentru proiectele de dimensiuni medii. Pentru clienții la nivel de întreprindere, structura organizației devine mai complexă, dar urmează modelul de mai jos.

Dezvoltarea Salesforce se face de obicei în sandbox-ul pentru dezvoltatori (roșu), iar modificările sunt mutate în sandbox-ul de integrare (verde), care este de obicei un dezvoltator pro sau o copie parțială. Apoi, modificările de la mai multe sandbox-uri de integrare sunt mutate în sus în rollup sandbox (galben), care ar trebui să fie o copie parțială sandbox.

Dacă organizația dvs. are integrări cu sistemul terță parte care necesită testarea integrării și testarea încărcării, trebuie să aveți un set stabil de date care să nu se schimbe de la o ediție la alta. Deci, este mai bine să aveți o copie completă sau o copie parțială sandbox pentru aceasta.

Aceste modificări sunt apoi mutate în sandbox-ul de testare a integrării, unde sunt efectuate teste. Apoi, modificările sunt mutate în sandbox-ul de realizare, care ar trebui să fie un sandbox de copiere completă. Toate clasele de testare sunt rulate înainte de implementare. Ar trebui efectuată o validare a implementării pentru a vă asigura că implementarea are loc fără probleme.

Acest proces ne ajută să ne asigurăm că modificările trec prin mai multe runde de testare și perechi de ochi. Are un dezavantaj greu de a necesita mult timp pentru a dezvolta, testa și implementa modificări.

Foarte des, există o nevoie urgentă de a efectua remedieri de erori sau corecții. Pentru a le gestiona rapid, ar trebui să păstrați un sandbox pentru dezvoltatori, care ar împinge mici patch-uri direct în sandbox-ul rollup.

După cum am menționat anterior, un sandbox este o replică aproape exactă a metadatelor de producție, dar nu complet. Există o listă oficială de componente/funcții care sunt dezactivate într-un sandbox.

Un alt lucru de luat în considerare la reîmprospătarea unui sandbox este că acesta copiază doar metadatele și datele de producție. Nu există nicio modalitate de a copia metadatele dintr-un sandbox în altul sau chiar de a crea un sandbox gol fără configurații de metadate (cum ar fi organizațiile de dezvoltatori gratuite). Acest lucru devine uneori o provocare în situații din viața reală. Salesforce intenționează să rezolve această problemă, iar această funcție ar putea deveni în curând disponibilă general.

În plus, dacă aveți niște date sensibile în producție, la care considerați că echipa dvs. de dezvoltare sau de testare nu ar trebui să aibă acces, puteți crea șabloane sandbox pentru sandbox-uri copiate complet sau parțial.

Ce să luați în considerare atunci când implementați

Am acoperit practicile industriei de management al ciclului de viață al aplicațiilor în ecosistemul Salesforce. Gestionarea metadatelor și sandbox joacă un rol foarte important în crearea pachetelor de implementare și a sarcinilor utile. Pentru aplicațiile Salesforce mari și complexe, controlul versiunilor vă ajută să vă asigurați că modificările metadatelor sunt urmărite, contribuind și la crearea unei strategii de rollback.

Gestionarea Sandbox-ului este esențială pentru proiecte mari sau complexe. Dar Sandbox-urile sunt costisitoare în ecosistemul Salesforce, atât din punct de vedere al resurselor financiare, cât și al timpului. Formularea unei strategii pentru managementul sandbox este întotdeauna esențială pentru procesul de management al versiunilor.

Vă vom lăsa cu câteva puncte suplimentare de care ar fi bine să le aveți în vedere la următoarea implementare:

1. Doar 10.000 de fișiere sau un fișier ZIP de 39 MB pot fi implementate dintr-o singură mișcare. Desigur, dacă sarcina utilă este prea mare, trebuie să împărțiți pachetul în mai multe părți și apoi să faceți implementarea.
2. Dacă implementarea eșuează din cauza unei erori de request timeout , încercați să eliminați obiectele, câmpurile personalizate și profilurile din pachet. Implementarea acestor componente durează mai mult.
3. Dacă un tip de câmp este modificat sau au existat modificări în ierarhia rolurilor, atunci ar putea exista întârzieri mari din cauza recalculării datelor, necesitând ceva timp pentru finalizare.
4. Salesforce blochează orice componentă care este utilizată în prezent de un utilizator în sistem. Dacă încercăm să implementăm în timp ce acesta este cazul, implementarea va eșua.

Sperăm că această prezentare generală vă va ajuta în timpul următoarei lansări Salesforce.

Surse