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.
@@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.
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
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.
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
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?
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
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.
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?
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😈😈😈
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.
method cherry-pick resiko errornya nggak besar ya?
hati" ketika pake cherry-pick, yg penting teliti aja
@@mih5944 kalo g teliti bisa aja ketinggalan, makanya ada SOP yg aku buat. Kondisi ini karna user minta partial deployment tiap enhancement
@@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.
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
kalo boleh tahu bahasa apa bang yang di pake
@@ramdoni3935 Bahasa Indonesia itu bang
@@iqbhalsetyo:v
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.
@@ramdoni3935 dart bang
terimakasi atas insightnya bang, saya belajar banyak dari penjelasan ini
tujuan trunk based untuk minimalisir code review
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
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?
Thank youu mas eko
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
thank you infonya
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.
prod -> hotfix -> prod
hotfix -> dev -> stg -> prod
kalo hotfix dari dev bahaya karena ada kemungkinan changes lain ikut kebawa ke prod
kalian pakek git ??
@@nov_ver pakai FTP kak
@@nov_ver wkwkwk
Sampai 2024, masih pakai mercurial 😊
Bahas tentang Domain Driven Design dong
Simplenya pisah komponen ke dalam bagian kecil². Ddd tiap team Dev beda² prinsipnya
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?
@@fathur208 kalau yg saya tangkep seperti itu, nunggu yg jadwalnya duluan rilis ke prod, baru setelah itu yg jadwal berikutnya
di tempat saya kayanya branch dev nya kurang kepake, developer make branch masing2, kalok udah kelar langsung di merge ke UAT/Staging/QA wkwkw
@@patorikusutaru7483 bebas asal satu tujuan dan udh distujui
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😈😈😈
baru aja setup, udah dibahas ajaa wkkww
1 kata lucu "micro service saya kegedean"
Perasaan browser chrome-nya pak eko ada notifikasi update terus deh heran 😮💨
saya cukup 2
dev dan prod