Sunt sigur ca exista la fel de multe workflow-uri ca developeri, asa ca nu ma bag intr-o discutie de ce e mai bine sau nu. Fiecare cu ale lui.
Dar o sa explic cum cred eu ca e mai bine cand e vorba de grunt/sass/minificari/dist folders si cum evit eu probleme de genu. Da, teoretic e continuous integration. Cred ca cel mai simplu mod de a explica un workflow-ul e sa prezint workflow-ul meu.
In primul rand, orice cod care nu e scris de tine e ignorat de git. Asta include, node_modules, bower components si dist folders. Pur si simplu nu are rost sa il tii in git, cand codul tau e tot ce e nevoie pentru a genera site-ul cand folosest continuous integration.
Sa zicem ca trebuie sa dezvolti un site WP. Poate lucrezi cu altii sau nu, dar recomand sa creezi o organizatie in git si un repo pentru proiectul respectiv. Eu folosesc master pentru production si un dev branch pentru qa. Nimeni nu da commit la master si orice PR va intra in dev. O data pe saptamana sau cand crezi ca un “release” e necesar, faci un PR de la dev la master si gata.
Faza cu PR si branches e legat strans de continuous integration. Orice commit in master va initializa un build care va genera dist folderul tau. Orice commit in dev branch va genera un dist folder pentru qa. Fiecare dist are o versiune unica si il trimiti undeva ca sa-l salvezi. Poti face git releases cu un zip atasat, poti sa-l trimiti pe dropbox, poti folosi artefactory etc. E important si util sa ai access la o lista de “releasuri”, locatia nu prea conteaza.
Apropo, distul asta nu e doar o lista de fisiere JS/CSS concatenate. E proiectul complet. Toate tema WP de la cap la coada. Zic asta fiindca mi se pare ca tu consideri dist ca un fel de .tmp folder, dar de fapt ar trebui sa-l privesti ca un deliverable.
Asta e partea cu continuous integration. Continuous deployment se face dupa un successful build (gen toate testele sunt OK). Cand generezi un dist folder nou, il trimiti pe server live. Gen FTP sau heroku sau amazon sau orice, nu conteaza. Distul de la dev branch il trimiti la un qa environment, gen pe un subdomeniu al tau. Distul de la master il trimiti la locatia finala.
Binenteles, tu lucrezi de pe forkul tau doar. Nimeni niciodata nu trebuie sa dea commit in repo-ul organizatiei! Fiecare cu forkul lui.
In final, uite niste link-uri de la proiectele mele ce folosesc continuous X:
-
https://github.com/vilmosioo/Sky-Watch foloseste Travis. E public dar are o gramada de key private incriptate de travis pentru a trimite dist-ul generat pe site-ul meu prin FTP. Recomand sa creezi un FTP account pentru fiecare build separat, cu access minimum pentru proiectul respectiv. Ca nu toata lumea e nice
In special, uite cum e setat continuous integration aici
- Site-ul meu e intr-un cont privat pe bitbucket, dar iti pot da access sa vezi cum arata. Ala foloseste Codeship pentru continuous integration. Ideea e aceeasi ca travis si e similar, doar ca e gratis si pentru proiecte private
Hint: setarile serverului de continuous integration ar trebui sa fie in repo, nu pe server. Te ajuta daca vrei sa schimbi setari sau workflow intr-un singur commit, fara sa fie nevoie sa schimbi ceva in travis.
Hint 2: Daca esti smecher, faci continuous integration pentru */merge pe dev branch, sa rulezi toate testele pentru fiecare PR ce il deschizi, sa fii sigur ca e ok sa dai merge. Travis are o integrare smechera cu github pentru asta 
Sper ca ajuta
