Apakah DevOps terbatas pada perusahaan dengan produk SaaS?


26

Praktik yang menggambarkan DevOps, seperti pengiriman terus-menerus, otomasi, dll. Relevan dengan produk yang menyediakan layanan berkelanjutan, seperti produk SaaS.

Misalnya, perusahaan pengembang perangkat lunak yang sebagian besar mengerjakan proyek untuk klien lain mungkin tidak pernah dipelihara setelah proyek ini selesai. Dan proyek klien tidak dibagikan dengan klien lain, karena tidak relevan.

Apakah DevOps bahkan berlaku untuk perusahaan yang mengembangkan banyak proyek yang hanya satu kali? Apa praktik DevOps yang berlaku dalam kasus ini, jika sama sekali?

Jawaban:


32

Benar-benar tidak!

DevOps adalah tentang memecah silo tradisional (departemen) agar lebih efisien.

Komunikasi yang lebih baik antar tim, peningkatan visibilitas dan proses yang andal dan otomatis adalah cara untuk mencapai produk yang lebih baik.

Saya dulu bekerja untuk perusahaan media besar di mana kami akan mendukung alat internal dan mengembangkan situs web yang menghadap publik.

Manfaat DevOps dalam kasus kami adalah sebagai berikut:

  • Melalui pembangunan berkelanjutan, kami memberi tahu tim pengembangan lebih awal daripada nanti jika ada integrasi atau membangun masalah dengan kode mereka. Mereka dapat memperbaiki masalah sementara pikiran mereka masih pada potongan kode yang baru saja mereka lakukan.
  • Melalui pengujian dan pengiriman berkelanjutan (ke QA), kami memungkinkan tim QA untuk menemukan masalah lebih awal dan melaporkannya sebelumnya. Ini mengurangi waktu yang dibutuhkan untuk menemukan dan memperbaiki bug serta mengurangi kompleksitas investigasi ini.
  • Tanpa alat pengumpulan & agregasi log, kami memberikan akses kepada pengembang untuk sesuatu yang biasanya tidak mereka lihat (mereka sangat tertarik pada para debugger :) - memahami bagaimana log dilihat dan digunakan oleh tim lain meningkatkan kualitas keseluruhan log
  • Kami sering berbagi informasi dan membuat dokumentasi untuk berbagi pengetahuan antar tim, mencoba meruntuhkan tembok. Dengan memahami kebutuhan Ops, kami membuat beberapa panduan untuk apa yang harus selalu diingat ketika mem-bootstrap aplikasi (di mana / bagaimana mengelola properti, dll.). Dengan memahami realitas Dev (kode lebih banyak fitur, lebih cepat, gogogogo!), Kami dapat membuat ops membuat server dan kluster yang lebih sesuai dengan kebutuhan dev.
  • Kualitas penempatan secara keseluruhan juga sangat ditingkatkan. Penempatan ditangani oleh tim kami, jadi kami memiliki visibilitas yang sempurna baik untuk Ops maupun Dev. Ini menghilangkan banyak masalah yang berkaitan dengan "code hand-off" di mana dev akan menyerahkan paket dan dokumen satu halaman ke ops yang mengatakan "Instal ini!".

Secara keseluruhan, saya akan mengatakan bahwa terlepas dari apakah Anda memperbarui lingkungan produksi Anda sekali sehari atau sebulan sekali dan terlepas dari berapa banyak pelanggan yang Anda miliki atau model bisnis Anda, setiap perusahaan dapat menggunakan komunikasi yang lebih baik, alat yang lebih baik, visibilitas yang lebih baik, umpan balik yang lebih cepat, dll.


1
Memang, DevOps dapat diterapkan pada hampir semua organisasi pengembangan sw, bahkan untuk produk-produk besar yang diembed dengan hanya beberapa rilis publik per tahun - dengan menggunakan pengiriman terus menerus dalam pipa pengembangan mereka, mereka masih dapat menuai beberapa manfaat DevOps: kualitas yang lebih baik, pengurangan biaya, lepaskan prediktabilitas, dll.
Dan Cornilescu

Jawabannya memang mengingatkan SaaS, tidak benar-benar menjelaskan dengan baik bagaimana produk atau layanan non-SaaS bisa mendapatkan manfaat dari praktik ini.
Evgeny

Produk yang saya kerjakan bukanlah SaaS (justru sebaliknya). Tetapi alasannya tetap sama, tidak masalah apakah Anda SaaS atau tidak, DevOps mencoba meningkatkan produk dengan cara yang tidak tradisional. Saya tidak tahu apa-apa tentang model atau penawaran harga kami, itu tidak akan membuat banyak perbedaan.
Alexandre

13

Tim saya dan saya bertanggung jawab untuk mengembangkan "satu kali", produk yang pernah selesai diberikan kepada klien untuk pemeliharaan atau dalam beberapa kasus dikelola oleh kami dengan biaya tertentu.

Kami masih perlu mempertahankan jalur pengembangan yang solid untuk menangani umpan balik yang konstan dari klien kami untuk memastikan bahwa kami mengirimkan mereka sesuatu yang andal dan terbukti berjalan.

Meskipun klien tidak peduli dengan DevOps (dalam banyak kasus), itu tetap bermanfaat bagi kami. Dengan DevOps, kami dapat dengan cepat mendorong bangunan baru, sehingga klien dapat melihat umpan balik dalam hitungan menit bukan jam, dan kami juga dapat menangkap kesalahan / bug dengan pengujian kami melalui Jenkins / Travis.

Untuk memastikan strategi penempatan kami sama di seluruh proyek, kami fokus pada penampung aplikasi kami. Menggunakan Docker, kami dapat dengan mudah menyerahkan aplikasi kepada klien kami.

Biaya yang dihemat oleh DevOps sulit ditentukan. Kami memang memiliki biaya tambahan dalam bentuk perangkat lunak yang kami pilih untuk digunakan untuk saluran pipa (Travis, Jenkins, Puppet, apa pun yang Anda miliki), tetapi kami juga menghemat waktu dan uang dengan memperbaiki bug / memberikan umpan balik kepada klien dengan cepat. Waktu respons cepat kami membuat pelanggan senang, pada gilirannya, menjaga dompet kami bahagia.


Bisakah Anda memberikan beberapa alasan dan manfaat mengapa ini penting? Apakah klien benar-benar peduli dengan pipa Anda, atau hanya proyek yang selesai pada tanggal yang dijanjikan dan harga yang harus mereka bayar? Bisakah Anda memangkas biaya dengan tidak melakukan semua hal "devops-y" ini? Bisakah Anda mendapatkan lebih banyak jam ke proyek tanpa melakukan hal-hal ini dan mendapatkan lebih banyak uang untuk proyek (karena lebih lama)?
Evgeny

1
@ Evgeny DevOps membantu menyelesaikan proyek tepat waktu dan sesuai anggaran untuk alasan yang dijelaskan dalam jawaban saya. Dengan memotong DevOps, Anda juga akan memotong manfaat yang saya jelaskan. Bangunan dan pengujian sering membantu mempertahankan anggaran dan tepat waktu. Menemukan bug kemudian membutuhkan lebih banyak uang dan membutuhkan lebih banyak waktu untuk memperbaikinya, telah terbukti berulang kali. Klien tidak peduli dengan pipeline, tetapi semakin lama Anda menunggu umpan baliknya, semakin mahal dan memakan waktu penulisan ulang itu.
Alexandre

Bukankah itu hanya Agile Software Dev?
Evgeny

@ Evgeny Saya telah memperbarui jawaban saya untuk menjelaskan. Kami menggunakan Agile, tetapi itu tidak berarti kami tidak dapat memiliki mentalitas DevOps ..
Turtle

1
@ Evgeny Anda mungkin bisa menghemat beberapa dengan tidak memelihara tes unit Anda dan tes penerimaan, tetapi ini membangun Utang Teknis yang merupakan anti-pola DevOps. Anda mungkin lolos dengan itu selama beberapa minggu atau bulan, tetapi Anda akan segera berakhir (mungkin) dengan kekacauan yang sulit dipertahankan yang tidak mungkin diuji.
Steve Button

3

Saya telah bekerja untuk perusahaan yang memproduksi perangkat lunak sebagai produk shrink-wrap, sebagai penyebaran yang sepenuhnya diinstal dan didukung dan sebagai kode tertanam di perangkat. Di semua perusahaan tersebut, DevOps memberikan dukungan penting untuk pengembangan:

  • Otomatis, perangkat lunak yang dapat direproduksi, dengan konfigurasi kompiler, perpustakaan, dan alat bantu bangunan lain yang diketahui dan terkontrol.
  • Tes sistem otomatis yang dapat diulang untuk pengujian regresi dan untuk tes fungsionalitas baru.
  • Tindakan otomatis dan reguler lainnya (misalnya, cuplikan layar contoh yang terus diperbarui tersedia dalam semua bahasa yang didukung, untuk diverifikasi oleh penerjemah dan bagi penulis teknis untuk dimasukkan ke dalam manual pengguna).

Dalam semua kasus, ini adalah hal-hal yang dapat dilakukan oleh pengembang perorangan sebagai satu kali saja, tetapi itu tidak akan menjadi penggunaan waktu pengembang yang baik, juga tidak memiliki jaminan kontrol konfigurasi yang sama dengan yang dimiliki oleh bangunan otomatis.


Otomasi bukan setan. Komentar yang sama dengan jawaban David Bock di bawah ini akhirnya (maaf, komentar saya hilang saat saya turun, hanya menyadarinya)
Tensibai

3

Kegiatan pengembangan dan implementasi perangkat lunak sebelumnya tidak memerlukan integrasi yang mendalam antara departemen. Tetapi untuk hari ini perlu untuk bekerja sama erat semua departemen (Pengembangan, Operasi TI, Jaminan Kualitas, dll).

Untuk pengembang, perubahan adalah apa yang mereka bayar. Bisnis selalu membutuhkan perubahan agar sesuai dengan dunia modern. Pemahaman ini mendorong pengembang untuk menghasilkan jumlah perubahan semaksimal mungkin. Profesional TI memiliki pemahaman yang berbeda, di mana perubahan berbahaya. Masing-masing dari mereka berpikir bahwa itu berfungsi dengan benar, menguntungkan bisnis. Memang, jika kita menganggapnya secara terpisah, keduanya benar.

Semua karyawan harus memahami bahwa mereka adalah bagian dari satu proses tunggal. DevOps memupuk pemikiran, yang memungkinkan untuk menyadari bahwa keputusan pribadi dan tindakan semua orang harus diarahkan menuju realisasi satu tujuan. Dan keberhasilan harus diukur relatif terhadap seluruh siklus pengembangan-untuk-pengiriman, dan bukan dari keberhasilan peran individu. Sebagai hasil kerja sama erat antara pengembang dan spesialis pemeliharaan, generasi baru insinyur terbentuk, yang mengambil prestasi terbaik dari kedua disiplin ilmu dan menggabungkannya untuk kepentingan pengguna. Ini dimanifestasikan dalam penampilan tim lintas fungsional dengan pengalaman dalam pengembangan, manajemen konfigurasi, manajemen database, pengujian dan manajemen infrastruktur.

Jadi metodologi ini bermanfaat tidak hanya di SaaS.


0

Tidak semuanya. Meskipun sudah ada contoh bagus di utas ini, saya ingin membagikan anekdot saya sendiri. Pada tahun 2001 saya mewarisi proyek perangkat lunak dengan rilis yang melibatkan pembuatan CD. Dokumentasi untuk proses rilis termasuk 40 (!) Langkah-langkah yang didokumentasikan oleh insinyur sebelumnya, yang mencakup beberapa instruksi tulisan tangan yang konyol seperti "buka file konfigurasi ini dan ubah nama file .jar pada baris 41 untuk memasukkan nomor versi dari rilis baru ".

Kami secara otomatis mengotomatiskan setiap langkah dari proses pembangunan itu, mengganti instruksi tulisan tangan seperti itu dengan hal-hal seperti 'tambalan' yang ditulis dengan bash. Kami bahkan harus membuka tiket dengan vendor alat instal pihak ketiga untuk membuat file proyek mereka dapat ditambal.

Setelah proses itu diotomatisasi, kami membeli 'CD Jukebox'. Setiap malam setelah tes lulus, mesin build akan secara otomatis membuat CD instalasi baru. Penguji kami dapat datang keesokan paginya, mengambil disk, dan memastikan semuanya dapat diinstal.

Kami tentu memiliki loop umpan balik yang lebih ketat ketika kami dapat menggunakan perangkat lunak sebagai layanan, tetapi prinsip utama otomatisasi, umpan balik, waktu siklus, rilis kecil, dll. Semuanya berlaku.


Ini terkait otomatisasi, tetapi tidak terkait dengan organisasi devops dengan cara apa pun, saya tidak melihat referensi tentang tim disiplin plury di mana pun, hanya ops yang mengotomatiskan hal-hal yang mereka warisi
Tensibai

Ini tahun 2001 ... jauh sebelum DevOps berubah. Ini bukan hanya otomatisasi, saya percaya ini merampingkan manajemen proyek dengan cara yang persis sama yang akhirnya diberi label 'Budaya' DevOps. Dengan demikian, ini adalah contoh sikap DevOps di luar organisasi SaaS.
David Bock

DevOps bukan tentang otomatisasi, atau manajemen proyek. Ini tentang melanggar organisasi berbasis silo di root. Maaf, saya tidak merasa jawaban ini benar-benar berhubungan dengan Pertanyaan (ini tidak berarti tidak menarik, tetapi tidak di tempat yang tepat IMO, dan saya tidak melihat di mana itu sebenarnya berada, mungkin datang nanti)
Tensibai

Saya akan mencoba sekali lagi untuk mengklarifikasi - dengan memiliki potongan CD begitu konsisten dan cepat, kami bisa mendapatkan umpan balik dari QA jauh lebih cepat daripada yang bisa kami miliki sebelumnya. Ini mengurangi silo. Itu tidak menghilangkannya, karena butuh satu atau dua tahun lagi sebelum kami melumpuhkan wilayah kekuasaan di sekitar anggaran terpusat untuk kegiatan, tetapi itu jelas merupakan langkah penting dalam makig yang terjadi. Kami juga tahu lebih cepat ketika proses rilis rusak. Saya menghargai banyak hal kecil seperti ini sebagai jalur pribadi saya ke DevOps.
David Bock

Komentar terakhir ini lebih masuk akal untuk jawaban ini di bawah pertanyaan ini, Anda harus mengedit untuk memasukkannya, saya masih merasa ini tidak cocok dengan format ini, tetapi tampaknya posisi saya salah ketika saya mengamati evolusi keseluruhan dalam beta pribadi ini, jadi ... terserah kamu. Saya tidak dapat menghapus downvote saya tanpa edit untuk informasi
Tensibai
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.