Gitflow gak bagus?

Рет қаралды 12,147

Күн бұрын

Пікірлер

@yogyrd Ай бұрын

Kalo di tempat saya kerja, ada branch masing² developer, dev, stg, prd, & main. Semua kerja di branch masing² developer. Kalo sudah selesai harus request merge di branch dev (yg mana nnti akan dideploy ke server dev). Nah dsni saya sebagai techlead ada SOP yg saya terapkan. Setiap kalo commit wajib dicatat (tools internal kita). Hal ini untuk mengurangi resiko ketika deployment ke env berikutnya. Karena metode pindah branch saya pakek cherry-pick. Ketika udah ok di dev, maka ketika ada jadwal UAT dan user hanya minta beberapa item requerement saya bisa pilih² (jd g semua fitur). Di production juga metodenya sama ketika di staging. Ketika user minta rilis, maka branch prod bisa nulis changelog version dan di merge ke branch main, yg mana nantinya akan digunakan sebagai base dr versioning. NB: pendefinisian task/issue wajib detail menyesuaikan requirement.

@mih5944 Ай бұрын

method cherry-pick resiko errornya nggak besar ya?

@jjs44dhd88 Ай бұрын

hati" ketika pake cherry-pick, yg penting teliti aja

@yogyrd Ай бұрын

@@mih5944 kalo g teliti bisa aja ketinggalan, makanya ada SOP yg aku buat. Kondisi ini karna user minta partial deployment tiap enhancement

@yogyrd Ай бұрын

@@jjs44dhd88 yups bener, kalo kek gni emang harus diketati SOP nya. Pernah ada case developer ada kesalahan jalani SOP, tp masih bisa di-solve karna ada reportnya. Kek gni juga karna user minta partial delivery. Bahkan ada yg di-keep dlu sampek 6 bulan. Dan dalam 6 bulan itu ada enhancement/bug fix. Sementara pakek gni, belum nemu metode yg pas juga.

@bluecattss Ай бұрын

ditempat saya ada 3 branch master (production), staging, dan dev. Setiap programer yang mengerjakan fitur akan membuat PR sendiri dan nanti di PR ke dev (melalui proses pengecekan senior / leader) baru nanti masuk dev. ketika release staging yang pertama dilakuin adalah bump version ngebikin PR release buat menaikkan versi lalu di PR ke dev lalu bikin git tag nya juga sesuai version-nya setelah itu ngebuat PR dev ke staging, baru build apps untuk staging, kalau release production itu tinggal ngebikin PR dari staging ke master, setelah merge baru build apps untuk production-nya sory kalau bahasanya ngejelimet wkwk

@ramdoni3935 Ай бұрын

kalo boleh tahu bahasa apa bang yang di pake

@iqbhalsetyo Ай бұрын

@@ramdoni3935 Bahasa Indonesia itu bang

@agungwiranata3719 Ай бұрын

@@iqbhalsetyo:v

@flux.d Ай бұрын

Kalo misal ada 2 programmer, programmer 1 mengerjakan fitur A, programmer 2 mengerjakan fitur B. Dua fitur tersebut sudah ada di step staging branch, ketika di test di staging ternyata fitur A memiliki bug dan harus di perbaiki terlebih dahulu, sedangkan fitur B passed, tidak ada issue. Kalo mau release ke production PR dari branch staging ke main/master, akan menjadi blocking fitur B dong ya? Karna di staging masih ada bug dari fitur A.

@bluecattss 29 күн бұрын

@@ramdoni3935 dart bang

@ridhohery8295 Ай бұрын

terimakasi atas insightnya bang, saya belajar banyak dari penjelasan ini

@alvinxyz7419 Ай бұрын

tujuan trunk based untuk minimalisir code review

@RivaldoSilalahi-ju8fn Ай бұрын

berarti kalai trunk based development itu pakai tag release ya pak? kalau di CI/CD gimana cara mengautomisasi deployment di multi env. kalau git flow dengan branch per env bisa diautomisasi jika ada merge ke branch tersebut

@jenn9233 Ай бұрын

untuk kasus monolith kalau branch release/2024-12-20 sudah rilis yang mana mengharuskan pull branch release/2024-12-29 terhadap branch yang sudah rilis tetapi developer di branch release/2024-12-29 belum melakukan commit karna blm menyelesaikan kodenya bukankah kode itu akan hilang?

@bboydarknesz Ай бұрын

utk versi monolith, karena deploy ke environment dev tp terbatas sdgkan fitur2 release bnyk yg berdekatan itu ad solusi yg lbh baik g y? krn skrg jadinya, 1 env dev bs > 1 fitur release, jadi sering konflik khususny yg agk2 bersingungan perubahannya thanks

@prayuditirtabayu7244 Ай бұрын

Thank youu mas eko

@MicoWendy Ай бұрын

thank you infonya

@bfr1368 Ай бұрын

Bahas tentang Domain Driven Design dong

@_whitecatfullgrown Ай бұрын

Simplenya pisah komponen ke dalam bagian kecil². Ddd tiap team Dev beda² prinsipnya

@irvan_rifai Ай бұрын

baru aja setup, udah dibahas ajaa wkkww

@wahidfeb Ай бұрын

Gimana dengan hotfix di production? Flow saya biasanya bikin branch hotifx dari dev kemudian merge ke prod. Kemudian merge prod ke dev baru setelah nya lakukan fixing versi benar dengan flow normal dari dev ke staging baru kemudian kembali ke prod.

@alvinxyz7419 Ай бұрын

prod -> hotfix -> prod hotfix -> dev -> stg -> prod kalo hotfix dari dev bahaya karena ada kemungkinan changes lain ikut kebawa ke prod

@nov_ver Ай бұрын

kalian pakek git ??

@edwinsamodra Ай бұрын

@@nov_ver pakai FTP kak

@moh.yusrilmaqoshidana9679 Ай бұрын

@@nov_ver wkwkwk

@davidsatrio3847 Ай бұрын

Sampai 2024, masih pakai mercurial 😊

@patorikusutaru7483 Ай бұрын

di tempat saya kayanya branch dev nya kurang kepake, developer make branch masing2, kalok udah kelar langsung di merge ke UAT/Staging/QA wkwkw

@lebahsaham9947 Ай бұрын

@@patorikusutaru7483 bebas asal satu tujuan dan udh distujui

@fathur208 Ай бұрын

kang mau tanya, klo yang multi tim yang dijelasin kang eko berarti yg releasenya belakangan gabisa deploy ke server dev/stg/prod sebelum fitur yg duluan udah release sampai production ya kang?

@sigitzigit3726 Ай бұрын

@@fathur208 kalau yg saya tangkep seperti itu, nunggu yg jadwalnya duluan rilis ke prod, baru setelah itu yg jadwal berikutnya

@ramdoni3935 Ай бұрын

Mantaps kang boleh usul kaga kalo bisa kedepanya setiap courser baru yang publish ke udemy buat video nya with Wajah Kang .. jadi enakeunn euy ngeliatnya ada kontak2 wajah tidak monoton hanya suara wkwkwk .. apalagi Kang Eko kan blasteran USA -indo Khanedy marga😈😈😈