Cara Transisi ke DevOps dalam 6 Langkah Sederhana

Setahun yang lalu, para eksekutif di phoenixNAP memutuskan untuk memulai proyek baru - untuk menciptakan produk andalan yang akan menjadi bagian dari portofolio solusi. Para eksekutif menantang cara produk dikembangkan dan ingin mencari cara baru untuk meluncurkan produk dengan cepat.

Setelah diskusi internal, keputusannya adalah mencoba metode baru dalam mengembangkan produk. Keputusannya adalah menggunakan tim DevOps.

Dalam artikel ini, Peter Borg, SCRUM Master di phoenixNAP, menjelaskan langkah-langkah dan tantangan yang perlu diatasi untuk transisi ke budaya DevOps.

Langkah-langkah Transisi ke DevOps

Secara historis, perusahaan telah menghadapi beberapa masalah dengan pengaturan Agile tradisional, yang menyebabkan penundaan dalam penyelesaian proyek. Jika tim SCRUM beroperasi dengan kecepatan penuh untuk mencapai suatu tujuan, namun infrastrukturnya belum siap, pengiriman akan tertunda. Pemisahan departemen mungkin menciptakan situasi di mana tim pendukung mungkin tidak memiliki sumber daya untuk mendukung tim SCRUM. Satu departemen saja tidak menghasilkan produk perangkat lunak, dan itulah yang ingin kami ubah dengan beralih ke DevOps.

1. Ciptakan Tim Mandiri

Untuk memulai perubahan budaya DevOps yang baru, kami membentuk tim baru yang deskripsi tugasnya unik bagi perusahaan. Kami beralih dari pengembang full-stack ke insinyur perangkat lunak DevOps, dan dari SysAdmins ke Site Reliability Engineers (SREs).

Dengan melakukan hal ini, kami dapat membentuk tim yang mandiri, dan tujuannya adalah untuk menyelesaikan proyek yang ada. Mempekerjakan orang yang tepat sangatlah penting, selain memiliki keahlian dalam aspek spesifik dari rangkaian teknologi baru sehingga mereka dapat menghasilkan produk tanpa bergantung pada orang di luar tim.

SRE ditugaskan untuk membuat kode infrastruktur, Insinyur Perangkat Lunak untuk mengembangkan aplikasi, Insinyur QA untuk menyiapkan kerangka pengujian otomasi, dan Arsitek Perangkat Lunak dan Sistem untuk merancang solusi.

Meskipun orang-orang ditugaskan untuk tugas-tugas tertentu berdasarkan bidang pengetahuan mereka, kami mendorong penyerbukan silang pengetahuan. SRE berkontribusi pada kode perangkat lunak, insinyur perangkat lunak ikut serta dalam Infrastruktur-as-Code (IaC) kami, QA terlibat dalam strategi Test Driven Development (TDD) dan pipeline Continuous Integration (CI), dan Arsitek membantu pengembangan dan pemecahan masalah.

2. Merangkul Pengembangan Berbasis Tes

Semua orang membenci rilis besar-besaran, yang menyebabkan masalah dalam menemukan masalah integrasi yang terlambat, memfaktorkan ulang solusi yang kompleks, dan kemungkinan perbedaan visi produk.

Agar tidak terjebak dalam permasalahan ini, kami memilih pengembangan berbasis pengujian (TDD). TDD memungkinkan kami menguraikan, menerapkan, menguji, meninjau, dan memperluas solusi kompleks sambil selalu mendapatkan masukan dari Pemilik Produk (PO) saat kami terus mengembangkan produk. Pendekatan berulang dan umpan balik ini memberi kami kemampuan untuk terus meningkatkan fitur setelah membangun fondasi yang kuat, yang merupakan prinsip pertama dalam Agile Manifesto (Kent Beck et al., 2001). Pertimbangan paling penting yang perlu diingat ketika mengadopsi pendekatan DevOps adalah memastikan bahwa tim tidak terikat secara emosional pada penerapannya karena mungkin ada di suatu hari tetapi hilang di hari berikutnya.

Dengan memilih pendekatan TDD, kami mengimplementasikan permasalahan kompleks dengan solusi yang tidak direkayasa secara berlebihan. TDD adalah pendekatan berulang untuk mengembangkan fitur yang membuat pemfaktoran ulang lebih mudah dicapai sekaligus menambah kualitas pada solusi. “Mulailah dari suatu tempat dan belajar dari pengalaman” (John Shook. 2008. Mengelola untuk Belajar: Menggunakan Proses Manajemen A3 untuk Memecahkan Masalah, Mendapatkan Kesepakatan, Mentor, dan Memimpin).

3. Dorong Perubahan Budaya DevOps

Memperkenalkan perubahan budaya tidak hanya sulit. Ini melelahkan, membuat frustrasi, dan melemahkan semangat. Mendorong pola pikir yang berbeda dalam organisasi multi-struktural jauh lebih sulit daripada membangun budaya perusahaan dalam sebuah startup.

Itu sebabnya saya percaya perubahan dapat dicapai dengan memperlakukan mereka dengan cara yang sama. Jika Anda mencoba membangun metodologi penerapan yang berbeda dalam perusahaan yang sudah mapan, hal ini hanya dapat dicapai jika Anda membuat ekosistem organisasi mini. Bentuk struktur tim yang akan dianggap perusahaan sebagai startup ketika mengimplementasikan proyek baru.

Anda akan dihadapkan pada batasan-batasan, seperti “Kami tidak melakukan hal seperti itu” atau “Kami sudah mempunyai alat yang berbeda untuk melakukan hal tersebut. “Jika Anda mendengar pernyataan tersebut, Anda berada di jalur yang benar. Mempertanyakan proses dan alat perusahaan adalah hal pertama yang perlu Anda lakukan ketika mengusulkan perubahan budaya. Pertimbangkan apakah alat dan metode yang ada relevan atau tidak.

Dalam kasus kami, dengan mengajukan pertanyaan, kami dapat memanfaatkan teknologi Cloud Native, bukan sistem yang dianggap oleh perusahaan sebagai ‘standar’. Anda tidak akan mendapatkan dukungan dari semua orang dalam mendorong perubahan DevOps. Namun, mendapatkan dukungan dari para eksekutif puncak sangatlah penting. Ini akan membantu memotivasi orang-orang di dalam perusahaan yang kurang terbuka terhadap perubahan karena visi tersebut didukung oleh manajemen yang lebih tinggi.

4. Uji Kemajuan Anda

Uji kemajuan upaya Anda di berbagai tahap transisi DevOps.

Mulailah dengan menguji kecepatannya. Anda ingin gesit dan menerapkan solusi dengan cepat. Dengan membandingkan proyek 'startup' dengan solusi lain yang sedang berlangsung atau solusi historis, Anda akan dapat mengetahui apakah tim DevOps memberikan hasil lebih cepat. Penting juga untuk mengukur kemampuan tim dalam beradaptasi terhadap perubahan. Jika perubahan dari putaran umpan balik ternyata merupakan perombakan sistem, berarti ada yang tidak beres selama tahap desain.

Kedua, mengukur keberhasilan dengan menganalisis semangat tim. Masyarakat harus bersemangat dan termotivasi ketika adaptasi implementasi baru diperkenalkan. Anda akan menyadari bahwa Anda telah mencapai hal ini dengan mendengar seseorang dari tim berbicara dengan seseorang di luar tim, menjelaskan bagaimana kami berhasil memecahkan masalah menggunakan mentalitas atau teknologi baru, yang baru bagi perusahaan. Hal ini akan memicu minat dari tim lain dan pada titik itulah Anda akan menyadari bahwa perubahan budaya menyebar ke seluruh organisasi. Pertimbangkan bahwa ukuran kesuksesan sebenarnya - metodologi DevOps yang baru akan diperhatikan. Anggota tim lainnya ingin mencoba berbagai hal secara berbeda dan mendatangi Anda untuk meminta saran tentang cara mengatasi masalah menggunakan solusi DevOps.

Pelajari lebih lanjut Metrik dan KPI DevOps yang harus Anda lacak.

5. Jangan Kompromi

Ketika saya mengambil peran SCRUM Master, saya tahu saya harus menghadirkan produk baru dan perubahan budaya DevOps secepat mungkin. Sangat penting untuk menjaga kedua tujuan tetap selaras selama fase pengembangan produk. Ketika dihadapkan pada tantangan seperti ini, dukungan dan kepercayaan dari para eksekutif dapat membuat atau menghancurkan perubahan budaya. Kadang-kadang, manajemen mungkin tidak memikirkan bagaimana suatu proyek dapat dicapai selama proyek tersebut dilaksanakan - bahkan jika kita harus kembali menggunakan teknologi yang sudah ketinggalan zaman.

Itu membawa saya ke poin berikutnya, mulai dengan kanvas kosong. Jangan mencoba menyesuaikan standar perusahaan saat ini ke dalam cara DevOps dalam mengembangkan perangkat lunak. Mulai dari awal dan pertahankan solusi ramping. Biarkan tim meneliti alat terbaik untuk memecahkan masalah. Jika mereka mengidentifikasi solusi yang sudah digunakan perusahaan, semuanya baik-baik saja. Jika tidak, berikan alat baru tersebut kepada siapa pun yang memperjuangkan solusi saat ini agar mereka setuju untuk mengubahnya. Pastikan tim mengingat bahwa tidak ada yang mutlak, peralatan dapat berubah, seseorang mungkin memiliki ide yang lebih baik, dan persyaratan dapat berubah; itu berulang.

6. Transisi Tim Lain ke DevOps

Setelah perubahan budaya DevOps dalam organisasi mikro ini mulai membuahkan hasil, Anda perlu mempertimbangkan langkah berikutnya - pertumbuhan.

Bagaimana cara mentransisikan lebih banyak tim ke DevOps?

Filosofi Toyota Production System (TPS) (Toshiko Narusawa & John Shook. 2009. Kaizen Express) tampaknya sejalan dengan model Agile Scaling Spotify. Mempertahankan struktur organisasi yang datar dan mandiri adalah kuncinya. Hal ini memberdayakan tim, membuat mereka lebih bertanggung jawab atas keberhasilan dan kegagalan mereka. Daripada membentuk departemen yang terdiri dari orang-orang yang memiliki keterampilan yang sama, buatlah ‘Bab’ di mana para anggota ini menjadi bagian dari tim SCRUM dan dorong mereka untuk bekerja sama satu sama lain untuk membantu memecahkan masalah. Mempromosikan komunikasi yang konstan mempertahankan prioritas proyek dalam tim..

Siapkan acara berbagi pengetahuan untuk memberi tahu departemen lain tentang keputusan teknis apa pun yang telah diambil tim. Berbagi pengetahuan akan membantu mendorong transisi seluruh perusahaan ke DevOps dan menggalang dukungan di seluruh organisasi. Kami telah belajar banyak selama setahun terakhir, dan kami terus mencari cara untuk meningkatkan proses dan struktur kami melalui berbagai proses. Mempertahankan mentalitas ramping dan gesit serta memastikan produk merupakan kisah sukses akan menjadi faktor terpenting yang harus dipertahankan.

Saran Terakhir untuk Beralih ke Devops

Poin terakhir dan terpenting bagi siapa pun yang bertransisi ke DevOps adalah jangan pernah menyerah. Akan ada saatnya Anda berpikir bahwa menerapkan budaya DevOps sulit untuk dicapai, namun jika Anda memiliki sistem pendukung yang tepat, mulai dari tim, manajemen, dan eksekutif, Anda akan mencapainya. Akan tiba suatu hari ketika seseorang dari tim lain akan meminta pertemuan dan ingin mengetahui bagaimana Anda menerapkan sesuatu.

Saat itulah Anda menyadari bahwa perusahaan berada di jalur yang benar untuk menerima budaya DevOps. Sebarkan filosofi dari satu tim ke tim lainnya, secara bertahap, dan luangkan waktu Anda untuk memindahkan seluruh organisasi ke DevOps.