Kereta Rilis Tenaga Penjualan: Pendekatan Praktis untuk Manajemen Rilis
Diterbitkan: 2022-03-11Manajemen rilis, seperti namanya, adalah proses pengelolaan, perencanaan, penjadwalan, dan pengendalian pembuatan perangkat lunak melalui berbagai tahapan dan lingkungan; termasuk menguji dan menyebarkan rilis perangkat lunak (Humble & Farley, 2011).
Ini adalah topik yang cukup besar dan hanya dapat disempurnakan dari waktu ke waktu dengan mencoba iterasi yang berbeda dengan tim pengembangan dan mencocokkan kebutuhan bisnis atau rilis fitur. Kami akan mencoba membahas praktik industri manajemen metadata, pembangunan CI, dan manajemen kotak pasir untuk mengelola rangkaian rilis organisasi .
Tapi apa itu kereta rilis?
Kereta rilis adalah teknik pengiriman fitur tambahan dan dapat diprediksi. Ini mengharuskan pengembang untuk menyiapkan proses formal untuk mengambil perubahan apa pun yang dibuat di lingkungan pengembangan dan menyebarkannya ke produksi.
Sebuah kereta rilis secara luas dapat dibagi menjadi tiga segmen:
- Manajemen metadata
- Membangun integrasi berkelanjutan
- Manajemen kotak pasir
Manajemen Metadata
Metadata adalah data yang memberikan informasi tentang data lain. Salesforce menyediakan model metadata yang kaya dan kuat melalui Metadata API -nya. Metadata aplikasi Anda menjelaskan dan mencakup serangkaian metode yang menyediakan akses terprogram ke kode sumber dan konfigurasi organisasi Anda.
Metadata API adalah cara terbaik untuk mengelola penyesuaian di Salesforce. Ini mendukung metode create , read , update , dan delete . Anda dapat menggunakan Change Sets, Force.com IDE, dan Ant Migration Tool untuk memigrasikan metadata dari satu organisasi ke organisasi lainnya, karena semuanya menyediakan migrasi melalui API.
Setiap alat memiliki kelebihannya sendiri, dan ada beberapa hal yang perlu dipertimbangkan saat memilih salah satu:
Tabel 1: Perbandingan Alat untuk Migrasi Metadata
| Ubah Set | Force.com IDE | Alat Migrasi Semut |
|---|---|---|
| Change Sets adalah cara untuk men-deploy komponen melalui UI Salesforce standar. | Force.com IDE (Eclipse) terutama ditujukan untuk pengembangan Apex, tetapi dapat digunakan untuk tujuan penerapan. | Ant Migration adalah alat baris perintah yang kuat, didedikasikan untuk memigrasikan perubahan/metadata antar lingkungan. |
| Biasanya digunakan untuk sejumlah kecil migrasi komponen. | Pengembang biasanya menggunakan IDE untuk memigrasikan perubahan ke lingkungan pengujian atau pementasan. | Migrasi Semut digunakan untuk migrasi muatan besar dan membutuhkan pengetahuan tingkat lanjut tentang Salesforce Metadata API. |
| Koneksi antar organisasi harus dibuat secara manual, sehingga tidak cocok untuk penerapan otomatis. | Ini dapat digunakan untuk menyebarkan ke organisasi mana pun, tetapi membutuhkan beberapa langkah manual, yang rawan kesalahan. | Penerapan otomatis dapat dijadwalkan dengan sangat mudah. |
| Ditujukan untuk digunakan oleh administrator. | Ditujukan untuk pengembang tenaga penjualan, karena mengembangkan kode adalah penggunaan utamanya. | Ditujukan untuk para insinyur DevOps. |
| Menambahkan dependensi sangat mudah dan ramah pengguna. | Menambahkan dependensi agak mudah, karena menyediakan titik dan klik UI. | Deployment biasanya gagal karena dependensi yang hilang. |
| Tidak mengizinkan perubahan yang merusak. | Apakah memungkinkan set perubahan destruktif tetapi prosesnya cukup membosankan. | Memungkinkan set perubahan destruktif. |
Metadata API sangat bagus dalam memenuhi tujuannya saat mengembangkan dan memigrasikan perubahan pada platform Force.com. Tetapi ada sedikit masalah - tidak semua metadata Salesforce didukung oleh Metadata API. Dokumentasi resmi menyediakan daftar komponen yang tidak didukung.
Jika organisasi Anda membuat perubahan yang tidak didukung oleh Metadata API, Anda harus memastikan untuk mereplikasi perubahan tersebut secara manual di organisasi tujuan. Cara terbaik melacak perubahan ini adalah dengan spreadsheet. Jika Anda harus menggunakan pendekatan ini, selalu disarankan bagi satu orang untuk membuat perubahan ini dan melacaknya.
Ini akan menjadi daftar kolom umum yang bagus yang dapat digunakan untuk melacak perubahan ini dalam spreadsheet:
- Nama komponen
- Jenis komponen
- Ganti pemilik
- Deskripsi fungsi
- Pemetaan kemampuan
- Ketergantungan dengan komponen lain
- Nama pengulas/pengulas
- URL
- Nama/ID organisasi
- Komentar lain
Kontrol Versi dan Integrasi Berkelanjutan
Memigrasikan perubahan ke produksi harus menjadi proses yang lancar, karena ini hanya pengulangan penerapan perubahan dalam lingkungan pengujian dan staging. Namun, selalu ada kemungkinan hal-hal berjalan ke selatan, dan kemudian Anda memerlukan rencana mundur. Sangat penting untuk menyimpan cadangan metadata organisasi Anda, dan untuk itulah kontrol versi dan build CI .
Kontrol versi adalah keharusan mutlak bagi organisasi mana pun. Ini memungkinkan pengembang untuk bekerja dengan cara yang kolaboratif, efisien, dan aman. Mengelola multi-developer, pengembangan kode multi-sandbox, dan migrasi merupakan tantangan di Salesforce. Salesforce juga memiliki jadwal rilis dan pemeliharaannya sendiri. Pembaruan ini memberikan fitur baru, tetapi mereka dapat memperkenalkan perubahan dalam Metadata API yang dapat merusak build CI Anda. Jadi, terlepas dari situasi di mana pengembang saling menimpa perubahan satu sama lain, kontrol versi membantu Anda dalam membangun strategi rollback. Memiliki strategi rollback adalah suatu keharusan ketika aplikasi Anda berjalan di Force.com.
Diagram alir berikut menggambarkan struktur praktis untuk Kontrol Versi dan CI. Kami akan mencoba memberi Anda deskripsi singkat tentang apa yang diwakili oleh diagram.
- Pengembang akan memeriksa perubahan mereka di sistem kontrol versi.
- CI Server/Jenkins akan menerapkan build terbaru ke sandbox CI dan menjalankan kelas pengujian.
- Jika penerapan di langkah 2 berhasil, maka perubahan akan digabungkan ke dalam cabang QA.
- CI kemudian akan menyebarkan komit terbaru dari cabang QA ke sandbox QA.
- Jika QA menolak perubahan karena kegagalan pengujian, langkah 1 sampai 3 harus dilakukan lagi sampai QA menghapus perubahan.
- Setelah perubahan lulus pengujian di QA, perubahan digabungkan ke dalam cabang Master.
- Perubahan terbaru dari cabang Master diterapkan ke kotak pasir Master.
Seseorang dapat memilih untuk menambahkan lebih banyak cabang tergantung pada kebutuhan organisasi. Tetapi struktur di atas hanya berfungsi dengan baik untuk struktur pengembangan tingkat menengah hingga perusahaan.
Manajemen Kotak Pasir
Untuk mendapatkan hasil maksimal dari proses DevOps organisasi Anda, sangat penting untuk menyiapkan struktur kotak pasir. Sebelum kita menyelam lebih dalam ke dalamnya, mari kita bahas berbagai jenis kotak pasir yang ditawarkan Salesforce kepada kita.
Kotak pasir adalah salinan yang hampir tepat dari metadata produksi seseorang. Kotak pasir biasanya digunakan untuk tujuan pengembangan, pengujian, pementasan, dan pelatihan. Ada empat jenis kotak pasir, dan seseorang harus memberikan pertimbangan saat memilih kotak pasir. Kotak pasir Salin Penuh bisa menghabiskan banyak uang!
Di bawah ini adalah tabel untuk batas yang diberlakukan oleh Salesforce untuk kotak pasir yang berbeda.
Tabel 2: Perbandingan Batas
| Pengembang | Pengembang Pro | Salinan Sebagian | Salinan Lengkap | |
|---|---|---|---|---|
| Data Produksi | Tidak | Tidak | Ya | Ya |
| Penyimpanan data | 200 MB | 1 GB | 5GB (10K catatan per objek) | Data Lengkap |
| Periode Penyegaran | 1 hari | 1 hari | 5 Hari | 29 Hari |
Kita dapat melihat bahwa harga bukanlah satu-satunya perbedaan antara kotak pasir.
Kotak pasir pengembang memiliki periode penyegaran satu hari, yang membuatnya cocok untuk pengembangan, tetapi hanya dapat menampung 200 MB data, dan tidak ada data produksi. Sebaliknya, kotak pasir salinan penuh memiliki salinan persis dari data produksi; bahkan ID rekamannya sama. Itu bisa membuatnya bagus untuk pengujian dan pementasan, tetapi periode penyegaran 29 hari menyulitkan untuk mendapatkan metadata dan data produksi terbaru di sandbox salinan lengkap.
Tabel di bawah ini berfungsi sebagai aturan praktis untuk memilih kotak pasir:
Tabel 3: Kasus Penggunaan untuk Pemilihan Sandbox
| Pengembang | Pengembang Pro | Salinan Sebagian | Salinan Lengkap | |
|---|---|---|---|---|
| Perkembangan | Ya | Ya | Tidak | Tidak |
| QA | Ya | Ya | Ya | Tidak |
| Tes integrasi | Tidak | Tidak | Ya | Ya |
| Tes Data Batch | Tidak | Tidak | Ya | Ya |
| Pelatihan | Tidak | Tidak | Ya | Ya |
| UAT | Tidak | Tidak | Ya | Ya |
| Uji beban | Tidak | Tidak | Tidak | Ya |
| Memanggungkan | Tidak | Tidak | Tidak | Ya |
| Pelatihan Pengguna | Tidak | Tidak | Tidak | Ya |
Di bawah ini adalah struktur organisasi khas yang diadopsi untuk proyek berukuran sedang. Untuk klien tingkat perusahaan, struktur organisasi menjadi lebih kompleks tetapi secara umum mengikuti model di bawah ini.
Pengembangan tenaga penjualan biasanya dilakukan di kotak pasir pengembang (merah) dan perubahan dipindahkan ke kotak pasir integrasi (hijau) yang biasanya pro pengembang atau kotak pasir salinan parsial. Kemudian perubahan dari beberapa kotak pasir integrasi dipindahkan ke kotak pasir rollup (kuning) yang seharusnya menjadi kotak pasir salinan sebagian.
Jika organisasi Anda memiliki integrasi dengan sistem pihak ketiga yang memerlukan pengujian integrasi dan pengujian beban untuk dilakukan, seseorang harus memiliki kumpulan data yang stabil yang tidak berubah dari rilis ke rilis. Jadi, lebih baik memiliki salinan lengkap atau kotak pasir salinan sebagian untuk itu.
Perubahan ini kemudian dipindahkan ke kotak pasir pengujian integrasi, tempat pengujian dilakukan. Kemudian perubahan dipindahkan ke kotak pasir pementasan, yang seharusnya merupakan kotak pasir salinan lengkap. Semua kelas pengujian dijalankan sebelum penerapan. Validasi penerapan harus dilakukan untuk memastikan bahwa penerapan terjadi tanpa masalah.
Proses ini membantu kami memastikan bahwa perubahan melewati beberapa putaran pengujian dan sepasang mata. Muncul dengan kelemahan berat yang membutuhkan banyak waktu untuk mengembangkan, menguji, dan menerapkan perubahan.
Sangat sering, ada kebutuhan mendesak untuk melakukan perbaikan bug atau patch. Untuk menangani ini dengan cepat, seseorang harus menyimpan kotak pasir pengembang, yang akan mendorong tambalan kecil langsung ke kotak pasir rollup.
Seperti disebutkan sebelumnya, kotak pasir adalah replika metadata produksi yang hampir sama persis, tetapi tidak sepenuhnya. Ada daftar resmi komponen/fitur yang dinonaktifkan di kotak pasir.
Hal lain yang perlu dipertimbangkan saat menyegarkan kotak pasir adalah hanya menyalin metadata dan data produksi. Tidak ada cara untuk menyalin metadata dari satu kotak pasir ke kotak pasir lainnya, atau bahkan membuat kotak pasir kosong tanpa konfigurasi metadata apa pun (seperti organisasi pengembang gratis). Ini terkadang menjadi tantangan dalam situasi kehidupan nyata. Salesforce memiliki rencana untuk mengatasi masalah ini, dan fitur ini akan segera tersedia secara umum.
Selain itu, jika Anda memiliki beberapa data sensitif dalam produksi, yang menurut Anda tidak boleh diakses oleh tim pengembangan atau pengujian, Anda dapat membuat template kotak pasir untuk kotak pasir yang disalin sepenuhnya dan sebagian.
Apa yang Harus Dipertimbangkan Saat Anda Menyebarkan
Kami telah membahas praktik industri manajemen siklus hidup aplikasi di ekosistem Salesforce. Manajemen metadata dan sandbox memainkan peran yang sangat penting dalam membuat paket penerapan dan muatan. Untuk aplikasi Salesforce yang besar dan kompleks, kontrol versi membantu memastikan bahwa perubahan metadata dilacak sekaligus membantu dalam pembuatan strategi rollback.
Manajemen kotak pasir sangat penting untuk proyek besar atau kompleks. Tetapi Sandbox mahal dalam ekosistem Salesforce, baik dari segi sumber daya keuangan dan waktu. Merumuskan strategi untuk manajemen kotak pasir selalu penting untuk proses manajemen rilis.
Kami akan memberi Anda beberapa poin tambahan yang sebaiknya diingat selama penerapan Anda berikutnya:
- Hanya 10.000 file, atau file ZIP 39 MB, yang dapat digunakan sekaligus. Wajar jika payload terlalu besar, Anda harus membagi paket menjadi beberapa bagian dan kemudian melakukan deployment.
- Jika penerapan gagal karena kesalahan
request timeout, coba hapus objek, bidang khusus, dan profil dari paket. Komponen ini membutuhkan waktu lebih lama untuk diterapkan. - Jika jenis bidang diubah, atau ada perubahan dalam hierarki peran, maka mungkin ada penundaan yang lama karena penghitungan ulang data, yang memerlukan beberapa waktu untuk diselesaikan.
- Salesforce mengunci komponen apa pun yang sedang digunakan oleh pengguna dalam sistem. Jika kami mencoba untuk menyebarkan saat itu terjadi, penyebaran akan gagal.
Semoga ikhtisar ini akan membantu Anda selama rilis Salesforce berikutnya.