DevOps berarti pengembang sekarang bertanggung jawab atas infrastruktur dan rilis - tetapi apa driver di balik perubahan ini?

18

Saya akan meletakkan kartu saya di atas meja: Saya adalah seorang pengembang dan telah bekerja di "DevOps" dan non-budaya. Harus khawatir tentang infrastruktur dan rilis dan QA dan upacara terkait adalah gangguan besar dari penulisan kode yang baik.

Tetapi industri bergerak ke arah ini, jadi apa alasannya? Masalah apa yang ditimbulkan oleh model spesialisasi peran "lama"?

process devops

— Ben
sumber

4

Apakah Anda mengatakan bahwa kualitas kode Anda turun karena Anda melakukan hal-hal lain, atau jumlah kode Anda turun.

— Caleth

1

Ambil kartu Anda dari meja, tolong. Ini hanya berbunyi seperti keluhan apa adanya.

— svidgen

7

@viden Jika pertanyaan ini murni kata-kata kasar, itu akan berbeda tetapi OP berhak untuk mengungkapkan pendapat mereka serta mengajukan pertanyaan yang benar-benar valid.

— Robbie Dee

1

@robbie yakin. Anda akan memperhatikan bahwa saya tetap menjawabnya ... tetapi, bagian "opini" dari pertanyaan ini menghabiskan lebih dari setengah tubuh, diapit di antara pertanyaan dasar yang sama diulang, dan mengalihkan perhatian dari kemurnian potensial dari pertanyaan dasar dalam kasus ini. Tapi ya. Masih layak dijawab ..

— svidgen

19

Alasan utamanya adalah cloud.

Dulu kode Anda dikirim pada floppy disk, dan kemudian CD, dan kemudian disebarkan ke server, dan kemudian disebar ke dua server (untuk ketahanan) ... Dan semua penyebaran itu bisa dilakukan secara manual oleh manusia, jadi manusia dilatih untuk melakukannya.

Hari ini, kode Anda sering menuju lusinan atau ratusan server. Menyediakan, mengkonfigurasi, dan menggunakan ke server-server itu tidak dapat secara realistis dilakukan secara manual oleh manusia. Anda perlu admin sistem Anda untuk mengetahui skrip yang cukup untuk mengotomatiskan proses itu, karena Anda sekarang menggunakan Chef atau kerabatnya. Tapi sejujurnya, tidak ada cukup admin yang bisa melakukan itu. Jadi devs ditarik masuk untuk mengambil kendur.

Dan ya, menambahkan lebih banyak keterampilan ke persyaratan pengembang yang terus berkembang tentu saja akan mengurangi kompetensi mereka di tempat lain. The ide adalah bahwa memungkinkan wawasan dev untuk proses membangun / release, mereka dapat mengantisipasi masalah yang lebih baik, atau memiliki otonomi untuk memperbaikinya. Idenya adalah bahwa kualitas segalanya meningkat sejak rilis menang menyusul kerugian penulisan kode.

Saya skeptis bahwa pertukaran itu sepadan dengan orang-orang yang melakukannya.

— Telastyn
sumber

2

Anda kehilangan saya di " Alasan utama adalah pantat ".

— tedder42

15

Ada banyak alasan berbeda bagi berbagai organisasi untuk pindah ke DevOps.
Saya akan mencoba membuat daftar yang sering muncul.

Mengurangi waktu untuk mengubah siklus
Sering kali ada waktu yang lama antara mengajukan permintaan untuk perubahan dan benar-benar digunakan dan digunakan dalam organisasi. Pertama direncanakan dalam salah satu siklus pengembangan oleh pengembang dan setelah itu disampaikan direncanakan dalam salah satu siklus rilis operasi. Kedua siklus termasuk pengujian dan jika ada masalah yang ditemukan, kedua siklus diatur ulang. Dengan mengintegrasikan departemen pengembangan dan operasi, kami dapat merampingkan kedua proses.

Masalah Software vs Hardware.
Ingat kartun Bugs Bunny di mana Bugs dan Daffy berdebat apakah itu musim bebek atau musim kelinci? Sekarang bayangkan kita sebagai gantinya membuatnya dengan pengembang dan operasi di mana pengembang berpendapat itu adalah masalah perangkat keras dan operasi berpendapat itu adalah masalah perangkat lunak. Bagi pengguna akhir, ini adalah perbedaan tanpa perbedaan. Mereka hanya ingin itu diperbaiki.
Dengan menyatukan pengembang dan operasi, mereka harus memperbaiki masalah. Dan mungkin ternyata itu masalah perangkat lunak dan perangkat keras.

Kami vs. Mereka
Di banyak perusahaan, jarak antara penguji dan pengembang tumbuh karena mereka adalah departemen yang terpisah dan siklus pengembangan menjadi semakin formal dan terstandarisasi.
Dengan kedatangan Agile, pengembang dan penguji telah bekerja lebih dekat bersama-sama dan kami sudah mulai melihat sudut pandang satu sama lain pada siklus pengembangan dan bahkan mungkin menghormatinya.
Sesuatu yang serupa perlu terjadi antara pengembang dan operasi, karena ketika kedua bidang matang dan proses lebih lanjut meresmikan dan menstandarisasi, jarak antara departemen-departemen ini tumbuh. Jadi salah satu masalah dengan model tradisional adalah sepertinya "kita" vs. "mereka" untuk pengembang dan operasi. Keduanya tidak sepenuhnya memahami kesulitan dari tanggung jawab yang lain.

Harapan / Kelemahan
Dengan DevOps kedua spesialisasi akan mempelajari beberapa keterampilan yang secara tradisional dilakukan oleh yang lain. Tidak seorang pun akan mengharapkan administrator sistem untuk menjadi insinyur perangkat lunak atau pengembang untuk menjadi insinyur jaringan, tetapi keduanya diharapkan untuk mengambil sebagian tanggung jawab yang lain. Ini berarti bahwa ketika Anda benar-benar membutuhkan tangan tambahan, mereka ada di sana.

Dan ada beberapa sisi positif yang pasti untuk pengembang: Anda sekarang memiliki kontrol lebih besar terhadap lingkungan pengujian Anda, Anda akan merasa lebih mudah untuk memiliki perangkat lunak yang digunakan untuk pengguna dan memiliki lebih banyak orang di organisasi Anda untuk berbagi kecintaan Anda dengan kerajinan.

— Miguel van de Laar
sumber

4

+1 - Karena ini tentang pengguna akhir dan bukan hanya kode.

— JeffO

3

Menulis kode kualitas tidak cukup. Anda adalah bagian dari masalah atau bagian dari solusi.

Bagi banyak programmer, Anda menulis perangkat lunak yang dibayar oleh beberapa pengguna akhir. Menulis kode kualitas adalah hal yang baik, tetapi juga sesuatu yang dianggap klien / manajer Anda harus selalu lakukan dan lakukan dengan cepat. Ini seperti mengatakan tukang memotong papan secara akurat, tetapi apakah Anda benar-benar membangun sesuatu yang ingin dibayar seseorang?

DevOps memberi pengembang lebih banyak kontrol atas dan semoga memaksa kode mereka agar sejalan dengan hasil akhir. Siapa yang paling cocok untuk mengotomatiskan proses operasi? Kepuasan pengguna akhir adalah tolok ukur utama. Anda tidak hanya harus menulis kode kualitas, tetapi harus memuaskan pelanggan. Maaf, tidak ada yang akan kembali menggunakan baris kode. Mereka tidak peduli jika Anda membangun kerangka kerja ORM Anda sendiri dari awal seperti pembeli rumah biasa tidak peduli jika Anda menebang pohon dan membuat papan Anda sendiri. Adakah yang ingin mengulang semua file konfigurasi mereka karena "peningkatan" Anda mengembalikannya ke default?

Anda ingin memamerkan daging pengembang Anda? Bangun sesuatu yang orang ingin beli dan itu termasuk seluruh pengalaman pengguna. Sangat menyenangkan bahwa Anda menulis kode kualitas, tetapi sayangnya, Anda mungkin tidak mendapatkan bonus jika tidak dilepaskan untuk kepuasan klien yang membayar. Jangan ragu untuk menyalahkan QA, tetapi perusahaan Anda masih tidak memiliki cukup uang untuk membayar Anda lebih banyak.

— JeffO
sumber

2

Saya yakin Anda tahu betapa sulitnya mempekerjakan pengembang perangkat lunak yang baik. Dan sekarang kita membutuhkan mereka untuk menjadi analis bisnis yang baik, tertarik pada upacara QA dan khawatir tentang proses rilis. Jumlah orang yang memenuhi bilah baru akan semakin kecil.

— Ben

2

@ Ben: Tidak ada "dan sekarang"; ini adalah hal-hal yang dilakukan pengembang baik selama beberapa dekade sebelum seseorang berpikir DevOps adalah hal baru dan menciptakan istilah. Pekerjaan Anda sebagai pengembang adalah menyelesaikan masalah yang meluas mulai dari kebutuhan seseorang akan solusi hingga memastikan orang-orang yang harus menangani kode Anda setelah Anda menulisnya tidak mengalami kesulitan. Kurangi semua itu dan tidak ada yang akan peduli betapa indahnya pasak persegi Anda dibuat jika mereka membutuhkan kereta luncur sepuluh pound untuk mendorong mereka ke dalam lubang bundar.

— Blrfl

Ini sepertinya argumen yang menentang spesialisasi. Bahwa seseorang harus menjadi jack of all trades master of none. Itu tidak disarankan di industri lain, Anda tidak memiliki tukang listrik-tukang batu-tukang ledeng listrik yang mencoba memahami setiap hal kecil tentang membangun rumah

— Richard Tingle

2

@ RichardTingle: Tidak ada yang mengatakan Anda harus memahami segalanya, tetapi Anda harus memahami hal-hal yang akan disentuh produk Anda saat digunakan. Tukang ledeng harus cukup tahu tentang apa yang dilakukan oleh tukang listrik - atau setidaknya bekerja dengan tukang listrik - untuk mengetahui bahwa tidak aman untuk menjalankan pipa air dingin melalui kotak pemutus walaupun ada KO tersedia untuk melakukannya.

— Blrfl

Bahkan tidak berusaha menjawab pertanyaan itu. -1

— RubberDuck

2

Ini adalah sesuatu yang berjalan seiring dengan Agile & Scrum. Tidak ada lagi peran pekerjaan yang jelas - setiap orang adalah "pengembang".

Dan itu bukan hanya operasi. Pengembang sering harus melakukan analisis bisnis, pengujian, administrasi basis data & membangun peran manajer - daftarnya terus berlanjut.

Inti masalahnya adalah apa yang Anda sebut churn . Karena jumlah peran berbeda yang terlibat dalam proyek meningkat, semakin banyak pertemuan, kesalahpahaman & bentrokan sumber daya terjadi. Mendapatkan perangkat lunak di depan pengguna dengan cepat adalah akhir dari permainan dan segala sesuatu yang dapat menghalangi hal itu telah berlalu sedikit di pinggir jalan.

Ini bukan sepenuhnya hal yang buruk. Pengembang rata-rata memperluas keterampilan mereka meskipun kemacetan semakin sangat tipis sekarang. Ini juga mencegah argumen antara coders dan admin server tentang di mana masalah terletak ketika penyebaran berjalan seperti pir. Pengembang sering ingin mendorong keluar solusi dengan teknologi canggih dan admin server sering tidak tahu apa artinya ini dari admin POV sampai mereka disajikan dengan set instal.

Perusahaan yang berpikir lebih cerah dan lebih maju akhirnya mulai menyadari bahwa orang yang berbentuk T adalah hal yang baik. Namun, ada perbedaan antara berpikir bahwa itu adalah hal yang baik dan mengharapkan ini terjadi secara ajaib di mana budaya tradisional sebelumnya telah diadopsi.

— Robbie Dee
sumber

-1 "tidak lagi memiliki peran yang jelas - setiap orang adalah pengembang." Itu tidak benar sama sekali. Tim scrum seharusnya terdiri dari beragam orang, yang meliputi pengembang, seniman grafis, IT guys, dll. Peran tidak hilang, tetapi idenya sekarang mereka semua berada dalam satu tim, bukan departemen terpisah.

— Andy

1

@Andy Saya sarankan Anda membaca panduan scrum lagi: Scrum tidak mengenali judul untuk anggota Tim Pengembangan selain Pengembang, terlepas dari pekerjaan yang dilakukan oleh orang tersebut; tidak ada pengecualian untuk aturan ini . Orang memang mengkhususkan diri tetapi pada dasarnya, itu seharusnya menjadi entitas yang mengatur diri sendiri.

— Robbie Dee

Memanggil seseorang yang khusus membuat grafik di Photoshop, atau seseorang yang berperan menerjemahkan, seorang pengembang menyesatkan karena pengembang dalam proyek perangkat lunak secara universal dipahami sebagai pengembang perangkat lunak. Panduan scrum benar-benar salah dengan pernyataan itu.

— Andy

0

Saya yakin ada lebih dari beberapa alasan bagus bagi pengembang untuk juga mengelola operasi dan kontrol kualitas (kadang-kadang). Inilah mereka bertiga:

Minat
Beberapa pengembang sebenarnya ingin mengerjakan semua aspek produk. Jika mereka pandai , dan jika mereka mengisi kekosongan di tim atau memberikan dukungan yang baik untuk anggota tim yang ada di peran lain, mungkin tidak ada alasan untuk menghentikan mereka.
Biaya
Perusahaan besar dapat membeli karyawan khusus. Perusahaan kecil terkadang tidak bisa. Beberapa dari tempat-tempat ini dapat mempekerjakan 1 atau mungkin 2 atau 3 pengembang yang harus dapat dengan mudah mengerjakan pekerjaan.
Ukuran Proyek
Tidak setiap proyek adalah proyek banyak orang. Jika Anda sedang membangun aplikasi "kecil", mungkin akan membutuhkan lebih dari 1 orang untuk menyelesaikannya. Lebih dari itu, proyek-proyek kecil dengan banyak individu yang menjalankan peran tertentu menakutkan . Tidak ada yang punya cukup pekerjaan untuk dilakukan - bahkan jika Anda mampu menjaga mereka di sekitar untuk memutar-mutar ibu jari mereka selama 6 bulan, yang baik tidak akan tinggal. Jika mereka tidak bosan, mereka akan takut, atau Anda akan menyadari bahwa Anda membayar sedikit untuk tidak ada apa-apa. Apa pun itu, karyawan Anda yang baik akan pergi dan menyuruh semua orang menjauh dari Anda.

... Dan alasan lainnya, saya yakin.

— svidgen
sumber

0

"Harus khawatir tentang infrastruktur dan rilis dan QA dan upacara terkait adalah gangguan besar dari penulisan kode yang baik"

Pada intinya, saya pikir DevOps mengatakan bahwa mengkhawatirkan infrastruktur dan rilis dan QA IS menulis kode yang bagus.

Dalam peran sebelumnya yang beroperasi di budaya non-DevOps, saya punya banyak masalah yang, bisa dibilang, budaya DevOps bisa dicegah; masalah kinerja yang berkaitan dengan kode yang dikembangkan pada platform non-representatif, masalah pengkodean karakter di mana pengembang tidak mengetahui pengkodean karakter yang digunakan oleh klien, instruksi penggunaan yang dikodekan secara manual dan tidak cukup untuk tim Ops tanpa sedikit pun menebak-nebak -kerja.

Sekarang Anda dapat berdebat bahwa peningkatan spesialisasi pada sisi Dev dan Ops memungkinkan kami untuk mengatasi beberapa di antaranya, tetapi masih banyak yang hanya dapat diselesaikan melalui berbagi pengetahuan dan kerja di antara tim kami.

— matt freake
sumber

0

DevOps tidak harus berarti "Dev sekarang lakukan juga Ops". Istilah awalnya berarti "Dev dan Ops orang bekerja sama dengan erat dalam satu tim". Ini tidak berarti bahwa Ops orang perlu untuk menjadi lebih seperti Pengembang, karena mengotomatisasi hal memerlukan beberapa jenis pemrograman, dan cara manual lama tidak dipotong (lihat jawaban lain untuk elaborasi yang lebih rinci mengenai hal ini).

Dari Wikipedia :

DevOps (senyawa pengembangan dan operasi terpotong) adalah budaya, gerakan atau praktik yang menekankan kolaborasi dan komunikasi dari kedua pengembang perangkat lunak dan profesional teknologi informasi lainnya sambil mengotomatisasi proses pengiriman perangkat lunak dan perubahan infrastruktur

Jadi menurut saya sebenarnya jika Anda sebagai Dev memiliki tanggung jawab lama yang sama dan juga sekarang tanggung jawab Operasional, yang tampaknya salah perhitungan pada bagian manajemen. Dengan mengotomatiskan hal-hal itu sangat mungkin bahwa Anda akan membutuhkan lebih sedikit orang Ops dan sehingga sebenarnya ada penghematan biaya. Tetapi DevOps tentu saja tidak berarti "Mari kita singkirkan semua orang Ops dan biarkan Devs bekerja lebih keras".

Seperti yang sering terjadi pada Buzzwords, Difusi Semantik terjadi, dan tiba-tiba orang berpikir, "Mari kita buat Dev juga melakukan Ops, dan saya kira kita bisa menghemat uang ..."

— jhyot
sumber