Apa definisi DevOps yang valid untuk memperkenalkannya kepada seorang pemula?


16

Saya telah melakukan / membuat banyak presentasi terkait SCM, dan sekarang saya mencoba untuk "meningkatkan" ke penerus DevOps itu.

Apa yang selalu saya coba lakukan dalam presentasi saya, adalah membuat slide pengantar yang entah bagaimana termasuk pesan yang ingin saya sampaikan (dan yang kemudian saya uraikan di sisa presentasi saya). Ketika melakukan itu, saya mencoba menjawab pertanyaan saya sendiri seperti "Apa yang akan saya 1 sampai 3 frasa yang ingin saya gunakan jika saya punya 10 hingga 20 detik (hanya!) Untuk menjelaskannya kepada seseorang yang baru mengenalnya? * ".

Saya pikir saya tahu apa arti DevOps sebenarnya, dan tentang apa itu. Tetapi saya telah melihat beberapa penggunaan / konteks yang aneh dari DevOps (bahkan pada DevOps.SE ...). Itu membuat saya bertanya-tanya apakah mungkin apa yang saya pikirkan adalah DevOps, benar-benar salah.

Jadi apa yang secara umum disetujui untuk menjadi definisi DevOps?


Riwayat Komentar telah dipindahkan ke obrolan untuk direkam tentang bagaimana pertanyaan dapat ditingkatkan.
Tensibai

1
Hal utama yang saya pelajari dari berbicara dengan banyak orang adalah tidak ada definisi yang disepakati.
Boikot SE untuk Monica Cellio

merci @XiongChiamiov ... yang kedengarannya seperti Anda mungkin menyadari salah satu definisi lainnya ... Mengapa tidak mencoba mempostingnya sebagai jawaban tambahan?
Pierre.Vriens

Jawaban:


11

Singkatnya singkat

Dari Wikipedia :

DevOps ( gabungan dari " perangkat lunak DEV elopment " dan " teknologi informasi OP eration S ") adalah istilah yang digunakan untuk merujuk pada serangkaian praktik yang menekankan kolaborasi dan komunikasi dari pengembang perangkat lunak dan profesional teknologi informasi (TI) sambil mengotomatisasi proses pengiriman perangkat lunak dan perubahan infrastruktur.

Ini bertujuan untuk membangun budaya dan lingkungan di mana membangun , menguji , dan merilis perangkat lunak dapat terjadi dengan cepat, sering, dan lebih andal.

Dari Ikhtisar :

masukkan deskripsi gambar di sini

Diagram Venn menunjukkan DevOps sebagai titik temu pengembangan (rekayasa perangkat lunak), operasi , dan jaminan kualitas (QA)

Meskipun tidak ada "alat" tunggal untuk DevOps, melainkan seperangkat alat, juga dikenal sebagai rantai alat DevOps :

masukkan deskripsi gambar di sini

Ilustrasi menunjukkan tahapan dalam rantai alat DevOps

Ilustrasi DevOps

Di bawah ini adalah beberapa kutipan dari beberapa pertanyaan di DevOps.SE , yang semuanya sepertinya cocok / mengkonfirmasi bagian dari deskripsi DevOps di atas:

DevOPS BUKAN peran

Di bawah ini adalah beberapa kutipan dari beberapa pertanyaan di DevOps.SE , yang semuanya menggambarkan bahwa DevOps BUKAN peran:


10

Saya telah berlatih dan memberi nasihat tentang DevOps sebagai konsultan dengan klien yang berbeda selama hampir lima tahun sekarang, sebelum posisi saya saat ini, saya memegang peran dalam pengembangan perangkat lunak, operasi web, dan administrasi sistem. Dalam pengalaman pribadi saya, DevOps hadir dalam banyak rasa.

Pola Organisasi

DevOps Antipatterns:

  • NoOps dan NoDevs - tidak sepenuhnya DevOps dalam arti yang paling ketat, namun, tim-tim ini membangun dan mengoperasikan perangkat lunak tanpa garis pemisah antara Pengembangan dan Operasi. Tantangan dengan tim-tim ini jatuh tempo, tim Pengembangan mungkin ahli Pengembang Perangkat Lunak tetapi Operator pemula dan sebaliknya.

  • The DevOps Bridge - di sinilah satu atau lebih tim diberi tanggung jawab untuk mengambil pekerjaan dari tim pengembangan dan " Memproduksi " untuk membuatnya bisa beroperasi. Tantangan datang ke sekarang ada dua hand-off, yaitu Pengembangan → DevOps dan DevOps → Operasi.

  • Tim DevOps - ini bisa, bisa dibilang, bekerja jika tim memiliki tanggung jawab untuk membangun alat yang mendukung Model Operasi yang diaktifkan DevOps, namun, mungkin harus disebut "Tim Alat" atau "Tim Platform".

Pola DevOps:

  • Embedded DevOps - lebih umum disebut sebagai Platform Engineering, di mana ada seseorang dalam tim yang bertanggung jawab tetapi tidak bertanggung jawab untuk memberikan otomatisasi, alat dan infrastruktur untuk penyediaan dan penyebaran solusi, kadang-kadang juga termasuk mengoperasikan perangkat lunak - dalam pikiran saya , yang terakhir inilah yang sebenarnya mewakili DevOps.

  • DevOps yang dilembagakan - di mana tim proyek bersama-sama bertanggung jawab atas pengembangan dan pengoperasian paket perangkat lunak, membangun kepemilikan bersama dan loop umpan balik positif.

Praktik

Praktik DevOps yang sebenarnya dibangun di atas beberapa praktik lainnya, yaitu:

Masing-masing praktik di atas dibangun di atas yang lain, mungkin untuk tidak mengikuti praktik, namun, artinya siklus umpan balik penting tidak ada yang mungkin mengindikasikan "peluang yang hilang". Perbedaan utama antara mengikuti praktik-praktik lain dan DevOps adalah pengoperasian perangkat lunak dalam produksi .

Praktik DevOps

Tiga Cara

Dalam The Phoenix Project Gene Kim dan rekan penulisnya menjelaskan tiga cara DevOps :

Sistem berpikir

Sistem berpikir

Cara Pertama menekankan kinerja seluruh sistem, yang bertentangan dengan kinerja silo kerja atau departemen tertentu - ini bisa sebesar divisi (misalnya, Pengembangan atau Operasi TI) atau sekecil kontributor individu (mis. , pengembang, administrator sistem).

Dalam pengalaman saya, membuat Pengembang mempertimbangkan Masalah Operasional dan persyaratan Non-fungsional mencapai tujuan ini. Ini sangat banyak bagian dari aspek budaya DevOps.

Amplifikasi dari Umpan Balik

Amplifikasi dari Umpan Balik

Cara Kedua adalah tentang menciptakan loop umpan balik kanan ke kiri. Tujuan dari hampir semua inisiatif perbaikan proses adalah untuk mempersingkat dan memperkuat loop umpan balik sehingga koreksi yang diperlukan dapat terus dilakukan.

Saya umumnya mencapai ini melalui Integrasi / Pengiriman / Penempatan Berkelanjutan dan pemantauan dan peringatan bersama, sehingga sangat cocok dengan komponen alat DevOps.

Budaya Eksperimen dan Pembelajaran Berkelanjutan

Budaya Eksperimen dan Pembelajaran Berkelanjutan

Cara Ketiga adalah tentang menciptakan budaya yang menumbuhkan dua hal: eksperimen terus-menerus, mengambil risiko, dan belajar dari kegagalan; dan memahami bahwa pengulangan dan latihan adalah prasyarat untuk penguasaan.

Ini sangat cocok di ruang budaya , meskipun sangat bergantung pada alat dan proses untuk memungkinkan budaya tumbuh.


Jawaban yang sangat bagus! meskipun saya tersandung pada perbandingan grafik dari praktik yang berbeda ... terutama tentang gesit. Saya pikir itu istilah yang terlalu luas untuk dimiliki di sana. Pengujian dikecualikan meskipun beberapa metodologi tangkas menempatkan pengujian sebagai inti dari praktik mereka. Pernah bisa berpendapat bahwa DevOps (atau bisa tergantung pada bagaimana itu diterapkan) sangat lincah. Manifesto lincah menggambarkan lebih dari filsafat daripada aturan praktik yang terikat dengan baik. Menganggap lebih dari sekadar mengeluh, itu jawaban yang sangat bagus!
Newtopian

Saya tidak dapat mengambil kredit penuh untuk diagram itu, itu telah ditarik oleh banyak konsultan sebelum saya di banyak papan tulis di seluruh dunia. Saya kira itu menggambarkan praktik tangkas di mana tim berfokus pada membangun produk yang berpotensi digunakan dalam iterasi singkat, CI mengikuti sebagai praktik yang mengotomatiskan beberapa pekerjaan itu, C. Pengiriman otomatis sejauh mempersiapkan membangun untuk penyebaran, C. Penempatan sebenarnya dikerahkan yang membangun dan DevOps mengoperasikan perangkat lunak dalam produksi.
Richard Slater

4

Saya telah mendengar banyak sekali definisi DevOps. Mereka termasuk:

  • Pengembang menangani tugas operasi
  • Satu orang melakukan pekerjaan dua kali lebih banyak (dalam jumlah waktu yang sama)
  • Pengembang dan tim operasi saling bekerja sama
  • Operasi berfungsi untuk perkakas pengembang (sesuai "Web Ops")
  • Judul pekerjaan untuk seseorang yang menciptakan dan mengelola perangkat pengembang
  • Penggunaan otomatisasi dalam operasi
  • Penggunaan cloud publik dalam operasi
  • Pekerjaan yang menggabungkan aspek operasi, pengembangan, dan jaminan kualitas
  • Pekerjaan yang mencakup membantu tim pengembangan dan operasi bekerja bersama
  • Sebuah filosofi memecah hambatan antara tim
  • Memperlakukan infrastruktur sebagai kode
  • Apa yang Anda dapatkan ketika mantan insinyur perangkat lunak mulai beroperasi
  • Kata kunci yang sama sekali tidak berarti

Tidak ada konsensus umum tentang apa DevOps sebenarnya adalah . Beberapa tahun yang lalu kami memiliki masalah yang sama dengan "Agile", dan itu memiliki definisi tertulis .

Ketika memperkenalkan konsep Anda kepada pendatang baru, saya akan fokus pada memperkenalkan konsep, daripada menerapkan label, atau mereka akan berakhir dengan mendengar definisi yang bertentangan dan menjadi bingung. Misalnya, jika Anda mencoba berbicara tentang infrastruktur sebagai kode , beri tahu mereka bahwa Anda berbicara tentang infrastruktur sebagai kode. Semakin spesifik Anda, semakin baik, bahkan dengan definisi yang disepakati sebagian besar perusahaan lebih berfokus pada bagian-bagian tertentu dari filosofi.


2

Definisi yang selalu saya gunakan dalam situasi ini adalah sebagai berikut:

“Budaya penciptaan perangkat lunak yang menekankan komunikasi dan kolaborasi antara pengembangan perangkat lunak dan tim operasi sembari mengotomatiskan proses pengiriman perangkat lunak dan perubahan infrastruktur. Tujuan dari DevOps adalah untuk membuat proses pengembangan, pengujian, dan penyebaran perangkat lunak sesering, secepat dan secepat mungkin. ”

Namun, bersama dengan definisi, penting juga bagi mereka untuk memahami MENGAPA kita membutuhkan DevOps. Pastikan untuk memberi tahu mereka bahwa DevOps mengurangi kerusakan perangkat lunak lebih cepat, memungkinkan manajemen sumber daya yang lebih baik, lebih sedikit kesalahan manusia, kontrol versi yang lebih baik, lingkungan operasi yang stabil dll.


1

Dengan makalah penelitian ilmiah berikut untuk mengeksplorasi secara tepat pertanyaan ini, "Apa itu DevOps", definisi turunan DevOps yang diusulkan adalah:

DevOps adalah metodologi pengembangan yang bertujuan menjembatani kesenjangan antara Pembangunan (Pengembangan) dan Operasi (Operasi), menekankan komunikasi dan kolaborasi, integrasi berkelanjutan, jaminan kualitas dan pengiriman dengan penyebaran otomatis menggunakan serangkaian praktik pembangunan.

[Jabbari et al.] "Apa itu DevOps ?: Studi Pemetaan Sistematik tentang Definisi dan Praktek" (2016)


-2

Devops adalah praktik pengembangan aplikasi penulisan yang domain bisnisnya beroperasi. Di mana sebagian besar pengembangan aplikasi berfokus pada membangun aplikasi yang membiayai atau layanan kesehatan atau logistik atau video kucing, devops berfokus pada aplikasi yang memungkinkan pembangunan, penyebaran, pemantauan, dan pengumpulan metrik.

Tujuan utama harus selalu memungkinkan pembuat keputusan untuk menjadi pengambil keputusan . Bayangkan aplikasi seluler bank Anda. Ketika Anda meminta transfer, itu terjadi ketika Anda menekan tombol. Anda membuat keputusan, lalu mengambil keputusan. Hal yang sama dengan operasi Anda. Ketika orang yang tepat memutuskan beberapa pekerjaan siap untuk disebarkan ke produksi, mereka harus dapat menekan tombol dan "Hal Benar Terjadi". Demikian pula, mereka harus memiliki semua informasi yang diperlukan yang mereka butuhkan untuk membuat keputusan bisnis yang benar.

Ini bukan tentang memberi pebisnis akses shell ke server - itu tujuan membingungkan dengan implementasi. Ini tentang memberikan kenop dan tuas yang tepat dengan informasi yang benar dan pagar pengawal yang tepat untuk orang yang tepat sehingga pengambil keputusan adalah pengambil keputusan.


1
whose business domain is operations: Kemungkinan untuk memperluas ini, atau memberikan beberapa contoh?
Dawny33

Saya tidak setuju, devops adalah model organisasi untuk mendukung pengembangan perangkat lunak, bukan praktik pengembangan itu sendiri, Anda dapat melakukan pemrograman ekstrem dalam model devops (mixin dev, ops, klien dan penguji misalnya) (Sisa jawaban memiliki poin bagus btw )
Tensibai

Definisi dasar dari "Devops adalah praktik pengembangan aplikasi menulis yang domain bisnisnya beroperasi" bukan yang pernah saya lihat orang lain berlangganan. Menulis aplikasi, apa pun domain atau tujuannya, adalah pengembangan, bukan DevOps.
Adrian
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.