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?

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 :

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 :

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:

• Dari ' Apa perbedaan antara SRE dan DevOps? ':

  ... DevOps adalah tentang menjaga kode ...

• Dari ( jawaban untuk) ' Bagaimana cara saya menyewa seorang DevOps yang baik, cocok dengan perusahaan saya? ':

  ... Adalah kesalahan umum bahwa "DevOps" adalah peran dalam perusahaan. Kata itu hanya menunjukkan pergeseran organisasi dalam perusahaan perangkat lunak ...

• Dari ' Apakah organisasi saya perlu mengadopsi Agile Soft. Dev. sebelum mengadopsi DevOps? ':

  ... masih ada organisasi yang tidak berlatih Agile dalam pengembangan perangkat lunak mereka, yang mungkin tertarik mengadopsi DevOps ...

DevOPS BUKAN peran

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

• Dari ( jawaban untuk) ' Apa perbedaan antara Sysadmin dan DevOps Engineer? ':

  ... DevOps bukan sebuah peran (bila digunakan seperti itu lebih merupakan kata kunci daripada peran nyata).

• Dari ( jawaban untuk) ' Bagaimana cara saya menyewa seorang DevOps yang baik, cocok dengan perusahaan saya? ':

  ... Adalah kesalahan umum bahwa "DevOps" adalah peran dalam perusahaan. Kata itu hanya menunjukkan pergeseran organisasi dalam perusahaan perangkat lunak ...

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:

• Pengiriman tangkas
• Integrasi berkelanjutan
• Pengiriman terus menerus
• Penerapan berkelanjutan

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 .

Tiga Cara

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

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

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

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.

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.

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.

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)

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.