Saya perlu memberikan jawaban saya untuk pertanyaan ini dalam konteks apa DevOps itu, lebih khusus dalam transformasi DevOps saya telah menjadi bagian dari, DevOps adalah kepemilikan Siklus Hidup Pengembangan Perangkat Lunak penuh. Semua praktik dalam bagan adalah bagian penting dari DevOps, dan mereka memungkinkan dan mendukung Sistem Berpikir dan Penguatan Putaran Umpan Balik .
Namun, pembeda utama antara CI / CD dan DevOps adalah operasi perangkat lunak yang sebenarnya dalam lingkungan produksi, di mana ia dapat memberikan nilai kepada pelanggan dan bisnis yang dilayaninya.
Sebagai konsultan yang berpartisipasi dalam atau memimpin transformasi DevOps saya memiliki aspek-aspek berikut di depan pikiran saya:
Budaya : Seperti Dave cukup benar menunjukkan suatu budaya Continuous Eksperimentasi dan Belajar adalah penting untuk keberhasilan transformasi apapun. Dari sudut pandang DevOps, ini bermuara pada bagaimana kita menciptakan budaya yang mendukung model DevOps yang dipilih, model ini bisa menjadi "Anda Membangunnya, Anda Menjalankannya" atau bisa lebih sejalan dengan praktik Rekayasa Keandalan Situs Google .
Model Operasional : Ini adalah bagian dari proposisi bisnis yang mengartikulasikan bagaimana organisasi akan memberikan nilai, umumnya dengan mengartikulasikan People, Process, dan Tools yang digunakan yang diikat bersama pada tingkat tinggi. Tanpa model operasi, Anda tidak memiliki cetak biru untuk cara organisasi mengadopsi praktik-praktik yang didefinisikan budaya, ini, pada gilirannya, mengarah pada kurangnya kejelasan dan perilaku yang berbeda.
Aircover C-Level : Seringkali pekerjaan kita sebagai konsultan yang bekerja dalam program transformasi untuk membuat perubahan radikal pada cara bisnis bekerja. Anda akan membuat marah orang, dan beberapa orang tidak akan menyukai perubahan - penting bahwa Anda memiliki "penutup udara" dari atas untuk mengubah sesuatu dan bergerak maju.
Setelah level tinggi sudah ada, penting untuk menemukan sesuatu yang secara realistis dapat Anda berikan:
- Mulai sekecil mungkin, idealnya, setelah Anda memiliki beberapa orang yang memahami budaya, sketsa model operasi dan penerimaan dari para eksekutif, buatlah "Proyek yang Layak Minimum", jangan mencoba untuk mendidihkan laut dengan memperkenalkan DevOps kepada ribuan pemirsa. Tetapkan tujuan yang dapat dicapai:
- Mengotomatiskan pembuatan infrastruktur dari Produk X.
- Otomatis pengiriman Produk X ke Azure di semua lingkungan.
- Dukungan langsung dari agen outsourcing Y ke tim pengembangan di London.
- Buat satu set tes di sekitar fitur paling berisiko kami dan jalankan dalam integrasi berkesinambungan.
- Hebat Anda memiliki beberapa keberhasilan di bawah ikat pinggang Anda sekarang saatnya untuk mulai memanggang ini ke lebih banyak tim, tambahkan beberapa tim ke dalam campuran dan bangun dan berjalan. Jangan takut untuk menawarkan "Dukungan Sarung Tangan Putih" pada awalnya untuk membantu mereka dalam transisi; mereka akan membutuhkan banyak pegangan tangan selama beberapa minggu dan bulan mendatang.
- Sekarang Anda memiliki beberapa pengguna awal yang mengikuti cara kerja baru; Anda memiliki massa yang kritis, sekarang saatnya untuk mulai menginjili pekerjaan yang Anda lakukan dengan audiens yang lebih luas:
- Adakan sesi tunjukkan dan beri tahu secara teratur, minta para pengguna awal untuk menunjukkan seberapa sukses mereka.
- Tawarkan sesi drop-in untuk memungkinkan bagian lain dari organisasi untuk mengeksplorasi bagaimana mereka bisa bergabung dengan tim Anda.
- Aktifkan penciptaan Komunitas Praktek yang berfokus pada disiplin ilmu tertentu: Penerapan Berkelanjutan, Pengujian Otomatis, Komunikasi Bisnis, Manajemen Risiko, Pemantauan dan Peringatan, dll.
Tetap di jalur dan tutup transformasi dengan menyatukan seluruh organisasi. Pahami hubungan antara Siklus Gartner Hype dan Siklus Hidup Adopsi . Bersiaplah untuk Program Transformasi untuk jatuh ke dalam "Palung Kekecewaan", tetap di jalur dan menjaga tujuan akhir yang terlihat.
Untuk penjelajahan yang lebih dalam dari poin terakhir, baca Geoffrey A. Moore's Crossing the Chasm . Saya benar-benar dapat menulis sebuah buku tentang cara memberikan transformasi DevOps, namun pada saat saya selesai, mungkin tidak ada lagi transformasi DevOps yang dapat saya lakukan.
