Puncte:0

Cum să faceți față modificărilor de configurare în prod și de către mai mulți dezvoltatori?

drapel cn

Am două scenarii în gestionarea configurației cu care nu sunt sigur cum să le rezolv:

  1. Utilizatorul geek face modificări de configurare în producție. Care este cea mai bună practică pentru a importa aceste modificări în dev fără a distruge munca la care se lucrează în dev? git pull și drush cim ar suprascrie tot ceea ce lucrați în dev. Știu că există drush cim --partial, dar din câte am înțeles, acesta nu este modul recomandat de a face acest lucru (Sursă). Aș putea folosi, de asemenea, modulul de configurare numai pentru citire în prod pentru a evita deloc modificările de configurare, dar există câteva exemple în care utilizatorului ar trebui să i se permită să schimbe configurația.

  2. Doi dezvoltatori funcționează în mediile lor locale de dezvoltare: Cum mă pot asigura că unul nu suprascrie lucrul de la celălalt atunci când este împins în scenă sau prod, mai ales când au loc și modificări de configurare în prod (vezi 1)? Probabil că o modalitate de ramificare a git poate ajuta, dar aș putea folosi mai mult ajutor despre cum să-l folosesc exact.

Puncte:4
drapel us

Folosirea bună a ramificării git poate ajuta cu siguranță în acest sens. Principalul lucru este că fiecare ramură individuală are o bază de configurare stabilă: nimic din exteriorul ramurului nu ar trebui să schimbe starea de configurare în cadrul ramurului, astfel încât mai târziu, când este timpul să exportați configurația în ramură și să o îmbinați în producție, doar modificările relevante. la ramură sunt înregistrate.

O modalitate de a face acest lucru este să aveți o ramură principală numită producție, iar HEAD-ul acelei ramuri urmărește întotdeauna starea curentă de producție a bazei de cod. Sunteți cu toții de acord să nu vă angajați sau să îmbinați lucrurile producție dacă nu te pregătești să eliberezi acele lucruri live.

Când Arjun dorește să lucreze la o nouă caracteristică, își face o nouă ramură producție, și ei o numesc arjun-1.

A doua zi, Beth trebuie să remedieze o eroare, așa că își face noua ramură producție numit beth-1.

Între timp, managerul de conținut Ceci se află în interfața de utilizare a site-ului, creând formulare web, ceea ce înseamnă că face modificări live de configurare care diferă de starea de configurare a producție. Într-un fel, și ea se ramifică producție! De fapt, să mergem mai departe și să creăm un ceci-1 se ramifica din producție acum să reprezentăm asta, chiar dacă probabil că nu vom angaja nimic încă.

Câteva zile mai târziu, filialele respective ale lui Arjun și Beth au fost revizuite și acceptate, iar conducerea dorește să implementeze o nouă versiune cu munca lor pe site-ul live.

Primul lucru de făcut este să verificați ceci-1 ramură, exportați configurația live și trimiteți fișierele de configurare actualizate ceci-1.

Acum puteți continua să mergeți la producție: noua caracteristică arjun-1, remedierea erorilor beth-1, și actualizările de configurare live ceci-1. Pot exista conflicte de îmbinare de revizuit, dar nu ar trebui să vă faceți griji cu privire la suprascrierea accidentală a configurației altcuiva. Acest lucru se datorează faptului că fiecare ramură individuală a avut o bază consecventă de la care să-și exporte propriile modificări individuale de configurare.

Să presupunem că nu ai făcut un ceci-1 ramură. În schimb, ai fuzionat arjun-1 și beth-1 în producție, apoi a exportat configurația live și a trimis actualizările în direct producție. Te-ai încurcat! Ați schimbat baza pentru modificările configurației site-ului live ale lui Ceci. Se bazaseră pe starea producției fără ramurile lui Arjun și Beth. Exportarea acum va suprascrie orice modificări de configurare pe care le-au făcut.

Extect avatar
drapel cn
Multumesc mult pentru raspunsul detaliat!!!
Puncte:0
drapel de

Schimbări nu ar trebui făcute niciodată în producție. Modificările de configurare a producției ar trebui făcute local de către dezvoltatori. Conflictele de îmbinare ar trebui să fie sortate pe computerul lor local. Deci, ar merge așa:

  1. Dezvoltatorul verifică codul
  2. Dezvoltatorul face modificări exportă configurația
  3. Dezvoltatorul încearcă să împingă, este respins să facă noi comiteri
  4. Dezvoltatorul trage, vede modificări în configurație
  5. Dezvoltatorul importă o nouă configurație pentru a se asigura că se importă corect și că modificările din comiterea sa nu sunt perturbate
  6. Dezvoltatorul exportă configurația după ce a făcut remedieri, comite și trimite pe server

Orice modificare a configurației făcute direct pe serverele de la distanță ar trebui să fie suprascrisă cu fiecare apăsare. Acest lucru vă rezolvă problemele de mai sus, cu excepția poate:

există mai multe exemple în care utilizatorul ar trebui să aibă de fapt permisiunea pentru a schimba config.

Precum?

Les Lim avatar
drapel us
Cum ar fi: adăugarea sau configurarea formularelor web, rearanjarea blocurilor, adăugarea de roluri de utilizator, ajustarea fluxurilor de lucru, modificarea imaginilor implicite ale câmpului de imagine etc. Sigur, este grozav dacă toate acestea se pot întâmpla într-un mediu de dezvoltare controlat, dar majoritatea site-urilor Drupal nu au un echipa de dezvoltare care poate păstori toate aceste schimbări prin fluxul de lucru de implementare.
Extect avatar
drapel cn
Mulțumesc @Les Lim! Acestea sunt exact cazurile de utilizare la care mă refer. Unele proiecte au nevoie de mai multă flexibilitate sau proiectul este atât de mic încât nu există o echipă de dezvoltare disponibilă tot timpul pentru a face modificări într-un mediu de dezvoltare controlat. În ambele cazuri, se fac mai multe modificări în prod și tocmai aceasta este problema în care sunt confuz cum ar arăta cel mai bun flux de lucru (dacă există).
Jaypan avatar
drapel de
Personal am o discuție cu clienții că modificările de configurare, cum ar fi cele de mai sus, sunt construirea site-ului, nu managementul conținutului. Nu văd situații în care clienții ar trebui să adauge roluri de utilizator, să modifice fluxurile de lucru și să modifice imaginile implicite pe câmpuri. Construim site-uri pentru ca clienții să le folosească, deschiderea construirii site-urilor pentru clienți deschide probleme - cum ar fi aceasta!
Jaypan avatar
drapel de
Ar trebui să adaug, constructorul de layout poate fi folosit pentru a ocoli problema cu blocurile. Formularul web este cea mai mare problemă pe care o văd pentru tine. Nu-l folosesc totuși, deoarece deschide doar probleme din experiența mea. Excepția în care aș dori să-l folosesc ar fi în cazul în care cerința proiectului este ca clientul să poată construi propriile formulare.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.