Rekan kerja saya berkomitmen dan mendorong tanpa pengujian


113

Ketika rekan kerja saya berpikir bahwa tidak perlu melakukan tes pada PC-nya, dia membuat perubahan, melakukan dan kemudian mendorong. Kemudian dia menguji pada server produksi dan menyadari bahwa dia membuat kesalahan. Itu terjadi seminggu sekali. Sekarang saya melihat bahwa dia membuat 3 komit dan mendorong dengan penyebaran ke server produksi dalam 5 menit.

Saya mengatakan kepadanya beberapa kali bahwa ini bukan cara kerja yang baik dilakukan. Saya tidak ingin bersikap kasar kepadanya lagi dan dia berada dalam status yang sama dengan saya di perusahaan dan dia telah bekerja lebih dari saya di sini.

Saya ingin perilaku ini dihukum dengan cara tertentu atau menjadikannya tidak menyenangkan sebanyak mungkin.

Sebelum saya mulai, perusahaan itu menggunakan metode-metode antik, seperti FTP, dan tidak ada kontrol versi.

Saya memaksa mereka / kami untuk menggunakan Git, Bitbucket, Dploy.io, dan HipChat. Penyebaran tidak otomatis, seseorang harus masuk ke dply.io dan tekan tombol deploy.

Sekarang, bagaimana saya bisa memaksa mereka untuk tidak menguji pada server produksi? Sesuatu seperti bot HipChat dapat merasakan bahwa ada pengeditan berulang pada baris yang sama dan mengirimkan pemberitahuan kepada programmer.


1
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Insinyur Dunia

5
Karena Anda menggunakan Git, gunakan permintaan tarik untuk menerapkan ulasan kode sebelum bergabung menjadi master dan disebarkan ke produksi. Juga, hapus kredensial untuk masuk ke server penempatan. Pusatkan otoritas ini dalam non-pengembang. (Kepatuhan PCI yang diberlakukan oleh industri kartu kredit mensyaratkan hal ini.)
Barett

3
Dari sudut pandang tempat kerja, jika Anda adalah Rekan Kerja dengan orang ini dan bukan dengan cara apa pun atasan mereka, Anda tidak akan mendapatkan daya tarik dengan 'menghukum' mereka. Berfokuslah untuk menjaga kualitas kode terjamin, bukan retribusi untuk standar rekan kerja Anda yang longgar.
Zibbobz

2
Apakah dorongan ke repositori "sentral" selalu memicu penyebaran produksi? Jelas tidak seharusnya.
jpmc26

3
Saya membaca pertanyaan dan berkata pada diri sendiri bahwa orang itu harus Turki dan di sana Anda :) lihat ini bro: nvie.com/posts/a-successful-git-branching-model . Anda harus memiliki setidaknya dua cabang: master dan dev di mana pengembang hanya mendorong ke dev dan setelah pengujian Anda bergabung untuk menguasai dan menyebarkan.
Cemre

Jawaban:


92

Anda memerlukan proses Jaminan Kualitas (QA) yang tepat.

Dalam tim pengembangan perangkat lunak profesional, Anda tidak mendorong dari hak pengembangan ke produksi. Anda memiliki setidaknya tiga lingkungan terpisah: pengembangan, pementasan dan produksi.

Ketika Anda berpikir bahwa Anda mendapatkan sesuatu yang berfungsi di lingkungan pengembangan Anda, Anda mendorong untuk melakukan pementasan terlebih dahulu, di mana setiap komit diuji oleh tim QA, dan hanya jika tes itu berhasil, itu akan didorong ke produksi. Idealnya, pengembangan, pengujian dan mendorong produksi dilakukan oleh orang yang terpisah. Ini dapat dipastikan dengan mengonfigurasi sistem otomasi bangunan Anda dengan cara yang hanya dapat digunakan pengembang dari pengembangan hingga pementasan dan bahwa tim QA hanya dapat menyebar dari pementasan ke produksi.

Ketika Anda tidak dapat membujuk manajemen untuk mempekerjakan seseorang untuk melakukan QA Anda, maka mungkin salah satu dari Anda dapat memainkan peran itu untuk yang lain. Saya tidak pernah bekerja dengan diploy.io, tetapi beberapa sistem otomasi bangunan dapat dikonfigurasikan sedemikian rupa sehingga pengguna dapat menggunakan baik dari pengembangan hingga pementasan dan dari pementasan ke produksi, tetapi tidak melakukan keduanya untuk bangunan yang sama, sehingga orang kedua selalu diperlukan (tetapi pastikan Anda memiliki beberapa orang cadangan untuk saat-saat ketika salah satu dari Anda tidak ada).

Pilihan lain adalah meminta staf pendukung Anda melakukan QA. Ini mungkin tampak seperti pekerjaan tambahan bagi mereka, tetapi juga memastikan bahwa mereka mengetahui adanya perubahan pada aplikasi yang dapat menyelamatkan mereka beberapa pekerjaan dalam jangka panjang.


Gagasan Dukungan melakukan QA di mana itu melibatkan rilis ke Produksi tampaknya nyaman, tetapi tidak akan terbang karena alasan pemisahan fungsi. Dukungan yang bertanggung jawab atas dukungan di luar "pengujian programmer" harus membuat mereka mengetahui perubahan. Sangat sulit dengan empat pengembang dan tidak ada yang lain :-) Jika Anda mengubah Anda menjawab untuk langsung mendaftar ke pengaturan OP, maka itu tidak akan banyak berguna bagi orang lain ...
Bill Woodger

1
@ BillWoodger mengapa? Bagi mereka itu adalah sistem 'perubahan dan kembalikan yang akan datang'. Mereka tidak hanya mendapatkan manfaat dari melihat apa yang akan terjadi sebelum 'menjadi nyata', tetapi juga cara untuk mengembalikan ke versi terakhir dengan mudah jika semuanya memburuk. Jangan lupa pementasan env adalah pengujian akhir-programmer.
gbjbaanb

1
@ gbjbaanb karena menempatkan dukungan di posisi yang sama dan menyatakan kembali masalah aslinya. Dukungan umumnya akan memiliki akses darurat ke Produksi. Jika mereka juga memiliki akses lain, Anda memiliki masalah audit (jika itu penting). Jika ada yang bisa mengubah apa pun maka ada masalah. Tentu saja Dukungan harus mengetahui segalanya, mereka seharusnya tidak dapat melakukan semuanya. Itulah yang dikatakan oleh setiap auditor yang pernah terlibat dengan saya, dan mereka meyakinkan saya akan hal ini sejak lama.
Bill Woodger

@ BillWoodger Saya tidak yakin apa yang Anda katakan. Tim produksi yang saya tahu biasanya memiliki proses peluncuran sendiri yang mencakup lingkungan pengujian (hanya untuk memeriksa kesalahan konyol dulu). Dalam tim kecil, tidak ada alasan mengapa sistem pengujian ini tidak dapat dibagi oleh dev dan dukungan. Tidak ada perubahan yang diizinkan untuk itu - diisi oleh dev melalui otomatisasi dan dikonsumsi oleh dukungan. Tidak berbeda dengan memberi mereka kode pos yang sama. Auditor prihatin dengan proses, bukan implementasi dari proses-proses itu (kecuali bahwa mereka diikuti, tentu saja)
gbjbaanb

1
Auditor @gbjbaanb prihatin dengan orang-orang yang memiliki akses ke segalanya. Jika seorang pria Dukungan dapat mengubah program dalam Pengembangan dan membuatnya menjadi Produksi tanpa campur tangan orang lain, maka sistem akan terbuka. Tentu, dengan empat orang OP tidak ada "Dukungan" yang terpisah, dan pembagian fungsi yang memuaskan akan menjadi rumit.
Bill Woodger

54

Anda mungkin ingin mendapatkan server dev, dan lebih disukai lingkungan pementasan juga. Tidak seorang pun boleh mendorong dari lokal ke produksi kecuali untuk situs web pribadi mereka sendiri. Proses penyebaran Anda seharusnya hanya mendukung dev-> staging-> prod. Anda mungkin ingin seseorang yang bertanggung jawab untuk menandatangani rilis baru - tergantung pada organisasi, ini bisa menjadi pemimpin proyek, QA yang berdedikasi atau tugas yang berputar setiap minggu (dengan pengingat yang nyata misalnya hanya orang dengan mainan berbulu yang dapat melakukannya pada minggu itu). Dorong). Namun, diskusikan dengan tim Anda terlebih dahulu untuk mendapatkan dukungan (lihat di bawah).

Saya ingin perilaku ini dihukum dengan cara tertentu atau menjadikannya tidak menyenangkan sebanyak mungkin.

Anda bisa meminta suite pengujian Anda (Anda punya salah satunya, kan?) Termasuk cek yang menentukan apakah Anda berada di server produksi dan, jika ya, mengirim semua email di kantor berkata Looks like $username is testing on prod, watch out. Mungkin mempermalukan rekan kerja Anda di depan umum tidak menyenangkan. Atau Anda dapat membuat batasan teknis seperti IP-melarang tim Anda untuk melihat prod (yang dapat Anda angkat tetapi Anda harus menjustifikasi).

Tapi saya tidak merekomendasikannya, Anda akan terlihat seperti masalah, bukan orang yang menguji pada prod dan Anda bisa membuat diri Anda sangat tidak populer dengan orang-orang di tim yang tidak peduli.

Tentunya yang benar-benar Anda inginkan bukan agar perilaku ini dihukum tetapi agar tidak dihentikan ?

Saya memaksa mereka / kami untuk menggunakan [...]

Sangat bagus bahwa Anda menganjurkan peningkatan alur kerja, tetapi sepertinya Anda tidak terlalu memikirkan kolega Anda dan / atau bahwa Anda tidak memiliki dukungan penuh dari mereka. Hal ini kemungkinan mengakibatkan rekan setengah berinteraksi dengan alur kerja, melakukan minimum yang diperlukan untuk mendapatkan kode ke produksi dan tidak benar-benar mengikuti semangat alur kerja, yang akan berarti lebih banyak waktu dihabiskan untuk menyelesaikan. Dan ketika Anda menghabiskan lebih banyak waktu untuk membersihkan hasil interaksi yang tidak memadai dengan alur kerja (karena tidak ada orang lain yang peduli, kan?) Semua orang akan mempertanyakan alur kerja itu sendiri.

Jadi mulailah dengan percakapan.

Cari tahu mengapa hal itu terjadi (apakah mesin kolega Anda tidak sebagus pengujian? Apakah kolega Anda tidak yakin dengan cabang fitur atau terjebak dalam pola pikir svn di mana komit dan dorong sama?), Jelaskan mengapa merupakan masalah bagi Anda bahwa kode yang belum diuji berjalan pada dev / staging / prod, dan lihat apakah Anda dapat melakukan sesuatu untuk mengubah mengapa itu terjadi (kolega Anda akan lebih mungkin melakukan apa yang Anda inginkan jika Anda baru saja membuatnya lebih baik untuk menguji secara lokal daripada jika Anda baru saja mencaci maki mereka).

Jika Anda tidak dapat menyelesaikannya dan itu benar-benar mengarah pada perbedaan pendapat, jadwalkan diskusi di seluruh tim dalam pertemuan retrospektif Anda berikutnya, lihat apa yang dilakukan dan dipikirkan oleh rekan kerja Anda. Buat kasus Anda, tetapi dengarkan konsensus. Mungkin tim Anda mengatakan tidak apa-apa untuk menguji perbaikan tekstual secara lokal, dan Anda hanya memiliki aturan bahwa tidak ada fitur besar yang belum dicoba. Tuliskan dalam pertemuan dan bacakan apa yang Anda putuskan secara kolektif tentang apa yang diizinkan pada masing-masing lingkungan. Tetapkan tanggal dalam beberapa bulan untuk memeriksanya, mungkin secara retrospektif.


10
+1 untuk percakapan. Harus ada pemahaman bersama bahwa ini adalah masalah dan mengapa itu merupakan masalah. Hanya dengan demikianlah ada keberhasilan dengan solusi teknis.
Patrick

9
+1 untuk mendapatkan server dev / lingkungan pementasan. Sampai ada tempat nyata di luar mesin sendiri untuk mendorong hal-hal perilaku ini bukan sepenuhnya kesalahan rekan kerja. Hanya ada begitu banyak yang dapat dilakukan seseorang pada mesin mereka sendiri, dan jika tidak ada hal lain, lingkungan ekstra sering membantu perubahan proses pemikiran / sikap pada pengujian.
Joel Coehoorn

20

Di tempat kerja, kami menghindari ini dengan menggunakan Gerrit . Gerrit adalah sistem peninjauan kode yang bertindak sebagai gerbang ke cabang Git utama / produksi Anda yang secara konvensional disebut "master". Anda memiliki ulasan kode, bukan? Sepertinya Anda secara pribadi melakukannya dengan sangat baik. Dengan Gerrit, Anda mendorong ke semacam cabang pementasan yang, setelah Anda dan rekan kerja Anda melakukan proses peninjauan kode dengan memuaskan, Gerrit kemudian bergabung ke cabang master Anda. Anda bahkan dapat mengaitkan Gerrit ke server CI untuk menjalankan tes unit sebelum siapa pun mendapat email untuk meninjau perubahan. Jika Anda tidak memiliki server tempat Anda dapat menyiapkan alat CI, Codeship memiliki rencana gratis yang bagus untuk digunakan sebagai bukti konsep.

Terakhir, tentu saja, adalah untuk mengotomatiskan penyebaran produksi hanya dari produk-produk build yang disetujui yang telah selamat dari tinjauan kode dan pengujian unit. Ada beberapa teknologi keren yang muncul untuk ini, yang saya tidak akan menyebutkan karena khawatir itu akan menjadi umpan api.

Pergi ke atasan Anda dengan solusi. Yang ini berlaku bahkan untuk Anda, dan merupakan cara untuk meningkatkan kualitas kode semua orang, bukan hanya menghukum rekan kerja Anda.


17

Saya melihat ini sebagai masalah besar manusia - proses ada di sana dan alat ada di sana, tetapi prosesnya tidak diikuti.

Saya setuju dengan apa yang orang lain katakan di sini, tentang kemungkinan bahwa itu sangat mungkin pengembang yang bersangkutan hanya terjebak dalam SVN pola pikir, dan mungkin berpikir bahwa ia adalah mengikuti proses.

Saya menemukan bahwa cara terbaik untuk mengatasi masalah seperti ini, terutama di mana mungkin tidak ada atasan yang jelas, tidak berputar di sekitar hukuman atau penghapusan akses - ini hanya mengarah pada kebencian dan karena sepertinya Anda adalah pendukung keras mengikuti prosesnya (selalu ada satu, dan saya pernah menjadi 'lelaki itu' sebelumnya), Andalah yang paling bisa mengatasi panasnya. Berputar di sekitar membawa orang untuk menyetujui proses pertama

Di sinilah pertemuan terstruktur, seperti "pelajaran yang dipelajari" -jenis rapat setelah insiden besar dalam produksi, bisa sangat berguna. Cobalah membuat semua orang setuju, termasuk pengembang yang bersangkutan, bahwa tinjauan kode, pengujian unit, pengujian komprehensif, dll. Semua harus dilakukan setiap waktu (dan Anda dapat mulai memperkenalkan gagasan tentang lingkungan pementasan di sini juga). Seharusnya tidak sulit, dan itu sangat masuk akal. Kemudian minta tim untuk membuat beberapa aturan yang solid bersama, tentang bagaimana hal itu harus dilakukan. Semakin banyak pengembang yang menyebabkan masalah berkontribusi, semakin mereka akan merasa seperti mematuhi aturan, dan mulai melihat mengapa perilaku mereka menjadi masalah.

Poin terakhir, jangan pernah jatuh ke "baik, itu lebih baik daripada dulu!" perangkap. Selalu ada ruang untuk perbaikan. Adalah umum bagi orang-orang di industri IT, dalam pengalaman saya, untuk mulai menerima apa yang mereka miliki, setelah beberapa perbaikan. Penyelesaian kemudian berlanjut, sampai Anda tiba-tiba berada di titik krisis lagi.


1
Saya benar-benar tidak jelas bagaimana "melakukan / mendorong, menyebarkan ke produksi segera, dan menguji perubahan Anda di sana dan di tempat lain" adalah pola pikir SVN ... Satu-satunya bagian dari proses yang akan melibatkan SVN adalah komitmen. Bahkan dengan model cabang tunggal atau kontrol sumber, komit tidak selalu menyiratkan penyebaran produksi. Atau setidaknya, seharusnya tidak.
jpmc26

@ jpmc26: Dengan risiko perang api Git / SVN: Kami mewarisi sistem SVN untuk sebagian besar kode "lawas" kami tetapi telah menggunakan Git untuk pekerjaan baru kami. Saya hampir dapat menjamin bahwa kami tidak memiliki pengaturan SVN yang benar dan / atau tidak menggunakannya dengan benar, tetapi penanganan cabang Git terasa jauh lebih mudah untuk dikerjakan. Saya 100% yakin SVN lebih dari mampu menangani penyebaran yang tepat, tetapi saya juga dapat melihat (dari pengalaman saya yang tidak sempurna) bagaimana SVN mungkin "menghalangi Anda lebih sedikit" dari melakukan hal yang benar. Bagaimanapun, ini hanya akan menjadi faktor kontribusi dan pendidikan pengguna lebih penting.
TripeHound

1
@ TripeHound Tidak ada argumen tentang sistem git yang secara keseluruhan lebih baik untuk mengelola perubahan kode Anda. (Keberatan saya dengan git umumnya berkaitan dengan kurva pembelajaran yang tinggi.) Maksud saya lebih dari itu sementara git mungkin memiliki lebih banyak kemampuan untuk membantu mengelola proses rilis Anda, cara Anda mengatur infrastruktur build Anda masih merupakan faktor utama di atas Anda pilihan kontrol sumber. Saya memiliki build dan release automation yang cukup sukses di SVN selama beberapa waktu, jadi saya tidak begitu jelas tentang apa itu "pola pikir SVN" atau bagaimana hal itu berdampak negatif pada rilis Anda.
jpmc26

2
Hanya karena Anda berkomitmen untuk menguasai bukan berarti Anda harus menggunakan untuk produksi. Bahkan jika repo / svn asal Anda di-host pada server prod, ini tidak menyiratkan hal seperti itu.
vonPetrushev

12

Ini tidak biasa , terutama di tim kecil. Jangan membuat masalah besar tentang hal itu, tetapi buat aturan informal:

Hancurkan bangunan, bawa donat.

Salah satu dari 1) Anda akan mendapatkan donat dua kali seminggu atau 2) mereka akan mematuhi standar.

Bawa itu dalam rapat. Tidak menuduh, jangan menyebut siapa pun dengan nama, tetapi sesuatu yang mirip dengan, "Sejak kami memperkenalkan kontrol versi dan standar penerapan, segalanya menjadi jauh lebih mudah dan server lebih banyak dari waktu yang biasanya. Ini hebat! Namun masih tergoda untuk mengambil jalan pintas dan mengirim tanpa pengujian yang tepat. Ini adalah pertaruhan, dan server kami ada di jalur. Saya menyarankan bahwa mulai sekarang jika ada di antara kita yang mengirimkan kode yang merusak server, orang yang bertanggung jawab membawa masuk donat untuk tim pada hari berikutnya. "

Ganti sesuatu yang lain untuk donat jika diinginkan, dan jangan membuatnya mahal - makan siang untuk seluruh tim akan terlalu banyak, tetapi kotak donat $ 5 atau nampan buah / sayuran, atau keripik dan celup, dll, dll mungkin akan mengganggu cukup untuk membuat mereka benar-benar menimbang risiko terhadap kemudahan melewatkan pengujian tanpa menjadikannya beban yang akan mendorong mereka menjauh dari tim atau perusahaan.


2
Ini hanya bekerja dengan kantor. Untuk apa konsep yang setara ketika Anda memiliki tim pengembang jarak jauh terdistribusi yang semuanya bekerja dari rumah?
Agustus

2
@aroth Untuk beberapa tim, email seluruh tim sederhana dari orang yang melanggar pembangunan sudah cukup. Rencanakan sebagai "tujuan peningkatan proses berkelanjutan" dan minta agar email berisi cukup informasi sehingga orang lain dapat melihat apa yang salah, mengapa itu salah, dan apa yang orang itu akan ubah tentang proses mereka, atau apa yang mereka sarankan kepada tim untuk diubah tentang proses, untuk mencegahnya terjadi lagi. Kebanyakan orang membenci laporan dan pelaporan, dan sekali lagi cukup jengkel sehingga mereka mungkin lebih berhati-hati untuk tidak merusak bangunan di masa depan.
Adam Davis

8

Sekarang, bagaimana saya bisa memaksa mereka ...

Alih-alih memaksa kolega Anda, cobalah membuat mereka melihat sesuatu dari sudut pandang Anda. Ini akan membuat segalanya lebih mudah bagi semua orang. Yang membawaku ke ...

Saya ingin perilaku ini dihukum dengan cara tertentu atau menjadikannya tidak menyenangkan sebanyak mungkin.

Mengapa Anda merasa kesulitan dengan masalah di server langsung, tetapi tidak untuk orang ini? Apakah Anda tahu sesuatu yang tidak dia ketahui? Apa yang dapat Anda lakukan untuk membuatnya melihat hal-hal seperti yang Anda lakukan?

Jika Anda berhasil dengan ini, Anda akan mengeluarkan yang terbaik dalam dirinya dan dia akan menemukan solusi untuk masalah yang tidak pernah Anda pikirkan.

Secara umum, cobalah bekerja sama dengan orang-orang untuk memecahkan masalah daripada memaksa mereka ke dalam proses yang tidak dimengerti.


6

Apa hal terburuk yang bisa terjadi? Apakah Anda memiliki cadangan yang cukup baik sehingga bug yang memodifikasi catatan acak di database Anda dapat diperbaiki dengan mengembalikan versi lama?

Katakanlah Anda memiliki bug di mana Anda menggunakan id rekaman, dan secara tidak sengaja jumlah tagihan dalam sen disimpan dalam variabel yang digunakan untuk id rekaman. Jadi jika saya membayar $ 12,34 maka catatan dengan id 1234 akan dimodifikasi. Bisakah Anda pulih dari itu, jika perangkat lunak berjalan selama beberapa jam hingga bug terdeteksi? (Jika record dan record 1234 yang benar diperbarui, Anda hanya akan mendeteksi ini ketika record 1234 digunakan, sehingga ini bisa tidak terdeteksi selama beberapa saat).

Sekarang tanyakan pengembang Anda yang sangat termotivasi apa pendapatnya tentang ini. Jelas dia tidak bisa mengklaim bahwa dia tidak pernah membuat kesalahan, karena dia pernah melakukannya di masa lalu.


"Apakah Anda memiliki cadangan yang cukup baik" - dan, meskipun demikian, apakah kolega Anda ingin menjadi muggin yang harus memulihkan cadangan karena ia merusak server? Mungkin ia suka pada prinsipnya untuk menguji sebelum penggelaran, tapi karena tidak ada lingkungan pengujian dia mengambil yang paling mudah pilihan yang tersedia saat ini. Maka membuat kasing untuk server uji harus mudah. Btw, bug yang tidak terdeteksi "untuk sementara waktu" akan membuatnya melalui uji coba untuk penyebaran karena masalah untuk bug tersebut adalah kualitas pengujian, bukan di mana pengujian dilakukan.
Steve Jessop

Anda tidak hanya memiliki cadangan, tetapi juga bisakah bisnis Anda membayar waktu henti sementara pemulihan dilakukan? Dan bisakah ia kehilangan menit, jam, atau bahkan berhari-hari informasi karena kemunduran database harus dilakukan? Saya akan mengatakan dalam hampir semua kasus nontrivial, jawabannya adalah 'tidak'. Dan bahkan dalam kasus-kasus sepele, Anda tidak ingin 'mengembalikan cadangan' menjadi cara Anda menangani kode yang belum diuji, harus diperiksa. Harus ada sesuatu yang memastikan bahwa pengujian terjadi antara saat kode diperiksa dan ketika mencapai produksi.
Agustus

Sepenuhnya setuju, itu sebabnya saya berkata "tanyakan pengembang Anda apa pendapatnya tentang itu". Dia benar-benar tertipu dan percaya kodenya bebas bug, atau dia tidak menyadari kerusakan yang bisa dia sebabkan. Atau kemungkinan ketiga, dia tahu dan tidak peduli.
gnasher729

3

Anda memahami dengan jelas berbagai kemungkinan proses dan solusi teknis. Masalahnya adalah bagaimana mengelola rekan kerja.

Ini pada dasarnya adalah latihan manajemen perubahan.

Pertama, saya akan berbicara dengan pendirinya untuk memastikan dia setuju dengan sudut pandang Anda. Jika ada pemadaman produksi, saya berharap bahwa pendiri akan sangat peduli tentang itu dan perubahan keinginan.

Kedua, Anda bekerja dalam tim kecil dan sepertinya layak untuk melibatkan seluruh tim dalam peningkatan proses.

Menyiapkan retrospektif proses reguler (misalnya setiap minggu). Memiliki seluruh tim:

  • Identifikasi masalah
  • Gagasan sukarela untuk meningkatkan praktik kerja
  • Terlibat dalam menerapkan praktik-praktik tersebut

Seharusnya mengikuti secara alami bahwa seluruh tim kemudian juga membantu memastikan kepatuhan dengan praktik yang ditingkatkan.


Retrospektif adalah cara yang bagus untuk mengatasi dan mudah-mudahan mengubah perilaku seperti itu dengan cara yang konstruktif!
greenSocksRock

1

Saya pikir Anda telah mengidentifikasi beberapa masalah:

  1. Kedengarannya seperti kode apa pun yang diperiksa dapat dengan mudah didorong ke produksi oleh siapa pun yang memiliki hak untuk memeriksa kode.

Terus terang saya pikir setup itu hanya gila. Minimal orang-orang yang dapat secara manual memicu dorongan untuk produksi harus dibatasi pada set orang yang dapat dipercaya sepenuhnya untuk meninjau dan menguji semua perubahan keluar secara menyeluruh (terlepas dari siapa yang telah membuat perubahan) sebelum memicu dorongan. Memberi siapa pun dengan izin untuk memeriksa dalam kode kekuatan untuk secara sewenang-wenang memicu produksi hanya meminta masalah. Tidak hanya dari pengembang yang ceroboh dan / atau tidak kompeten, tetapi juga dari yang tidak puas atau pihak ketiga jahat yang kebetulan membahayakan salah satu akun Anda.

Dan jika Anda akan menggunakan proses tombol-tekan untuk menyebarkan setiap perubahan yang diperiksa, maka Anda perlu memiliki rangkaian lengkap tes otomatis di tempat, dan menekan tombol perlu menjalankannya (dan batalkan penyebaran jika semua tes gagal!). Proses Anda seharusnya tidak mengizinkan kode yang bahkan belum diuji secara dangkal untuk mencapai titik di mana ia digunakan untuk sistem produksi.

Rekan kerja Anda telah melakukan kesalahan besar dalam hal memeriksa kode tanpa menguji terlebih dahulu. Organisasi Anda telah melakukan kesalahan yang jauh lebih besar dengan mengadopsi proses penyebaran yang memungkinkan kode yang belum diuji mencapai produksi dalam keadaan apa pun.

Jadi urutan pertama bisnis adalah memperbaiki proses penyebaran. Entah membatasi siapa yang dapat memicu dorongan untuk produksi, atau memasukkan sejumlah pengujian yang wajar ke dalam proses penyebaran otomatis Anda, atau keduanya.

  1. Sepertinya Anda mungkin belum menetapkan standar / prinsip pengembangan yang jelas.

Secara khusus, sepertinya Anda kehilangan " definisi selesai " yang jelas, dan / atau menggunakan yang tidak termasuk "kode telah diuji" sebagai faktor gating pada pemeriksaan kode dalam / menyebarkan kode ke produksi. Jika Anda memiliki ini, alih-alih hanya menunjukkan bahwa "kode yang baik tidak diproduksi dengan cara ini" Anda bisa mengatakan "kode ini tidak memenuhi standar minimum yang kita semua sepakati, dan harus lebih baik dalam masa depan".

Anda harus mencoba membangun budaya yang mengkomunikasikan dengan jelas apa yang diharapkan dari pengembang dan standar serta tingkat kualitas yang harus dijunjung tinggi. Menyiapkan definisi selesai yang mencakup setidaknya pengujian manual (atau lebih disukai, testcas otomatis yang dapat dijalankan sebagai bagian dari proses build / deploy) akan membantu dengan itu. Seperti dapat memiliki konsekuensi untuk melanggar build. Atau konsekuensi yang lebih parah karena melanggar sistem produksi. Perhatikan bahwa kedua hal tersebut harus benar-benar mandiri, dan seharusnya sama sekali tidak mungkin untuk menghancurkan baik sistem produksi maupun sistem produksi secara bersamaan (karena sistem yang rusak seharusnya tidak dapat digunakan).


0

Anda harus mengintegrasikan proses Tinjauan Integrasi + Peer Berkelanjutan di perusahaan. Bitbucket membuatnya mudah.

Dan +1 ke server dev disarankan oleh pengguna lain.

Jangan bersikap kasar padanya, itu hanya akan merusak hubungan kerja Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.