Manajemen kode sumber mencakup praktik, proses, dan alat untuk mengontrol, mengelola, dan melacak perubahan yang dilakukan pada basis kode dari waktu ke waktu. Juga disebut sebagai SCM, manajemen ini berfungsi sebagai sumber kebenaran definitif untuk tim pengembangan perangkat lunak dan pemangku kepentingan lainnya, termasuk tim DevOps, QA atau insinyur uji, spesialis keamanan dan penulis teknis.
Ketika proyek dan produk perangkat lunak tumbuh, kode sumber terkait mereka mungkin berubah menjadi kompleks dan sulit digunakan. SCM membantu mengubah kompleksitas dan kekeliruan itu menjadi sistem yang lebih mudah dikelola, yang mengarah pada kelincahan dan skalabilitas.
Manajemen kode sumber terdiri dari fitur-fitur utama ini:
Repositori
Kontrol versi
Percabangan
Commit
Penggabungan
Repositori, juga disebut repo, menampung kode sumber proyek dan artefak terkait lainnya, seperti skrip pembangunan, file konfigurasi, skrip basis data, dokumentasi, pengujian integrasi, dan pengujian unit. Anggaplah repo sebagai penyimpanan terorganisir atau gudang untuk produk piranti lunak.
Repositori terpusat dan bersama ini dapat di-hosting di tempat atau di cloud. Repo pribadi biasanya digunakan untuk sumber tertutup atau perangkat lunak hak milik, sementara perangkat lunak sumber terbuka menggunakan repo publik.
Tim pengembangan perangkat lunak dapat memilih antara dua arsitektur repositori utama:
Monorepo: monorepo menyimpan beberapa proyek dalam satu repositori. Repo jenis ini umumnya berlaku untuk komponen yang digabungkan erat.
Polrepo: Polrepo menyimpan proyek di repositori terpisah mereka sendiri. Arsitektur ini biasanya digunakan untuk komponen yang digabungkan secara longgar, seperti layanan mikro.
Kontrol versi memungkinkan tim untuk menyimpan riwayat basis kode. Repo jenis ini melacak berbagai versi file kode sumber dan artefak sehingga modifikasi dapat dilacak dan tidak akan hilang secara permanen. Pengembang dapat membandingkan kode sumber saat ini dengan riwayat versinya, kembali ke versi sebelumnya seperlunya dan membantu debugging. Riwayat versi ini juga dapat membentuk dasar catatan rilis, yang diterbitkan bersamaan dengan peluncuran atau pembaruan perangkat lunak.
Cabang adalah salinan terpisah dari repositori kode sumber yang dapat di-check-out dan dikloning ke lingkungan lokal pengembang. Sebuah repo dapat dibagi menjadi cabang yang berbeda, dan perubahan dapat dilakukan pada cabang tanpa memengaruhi repositori pusat. Dengan percabangan, anggota tim dapat menangani berbagai bagian basis kode secara bersamaan, sehingga mempermudah pengembangan paralel.
Cabang utama bertindak sebagai “batang” yang menjadi asal semua cabang dan bergabung kembali. Cabang utama ini berisi versi stabil terbaru atau rilis kode siap produksi.
Tim rekayasa perangkat lunak dapat mengadopsi strategi percabangan yang sesuai dengan kebutuhan mereka. Misalnya, mereka dapat membuat cabang khusus untuk setiap fitur baru dan cabang lain hanya untuk perbaikan bug, atau mengikuti alur kerja bertumpuk yang bercabang dari perubahan sebelumnya sehingga perubahan kode dibangun di atas satu sama lain.
Commit mencatat serangkaian perubahan pada kode sumber dan riwayat repositori. Sebagai praktik terbaik, commit atomik mewakili satu perubahan logis yang hanya menangani satu tugas spesifik, melewati semua pengujian yang diperlukan dan mengompilasi atau membangun tanpa gagal, sehingga kode tetap dalam status yang valid. Setiap commit harus disertai dengan pesan commit yang jelas dan bermakna yang menjelaskan apa yang berubah dan mengapa.
Penggabungan mengacu pada menggabungkan perubahan kode yang telah ulasan dan disetujui dari satu cabang ke cabang utama. Sebagian besar modifikasi dapat digabungkan secara otomatis. Dalam kasus di mana terjadi konflik, seperti ketika dua perubahan terpisah berdampak pada baris kode yang sama, penggabungan perlu dilakukan secara manual untuk menyelesaikan konflik tersebut.
Manajemen kode sumber dan kontrol versi sering digunakan secara bergantian tetapi mencerminkan tujuan yang berbeda.
Kontrol versi hanya membentuk satu bagian dari manajemen kode sumber. Kontrol ini berfokus pada pelacakan dan pengelolaan riwayat versi, sehingga memberinya ruang lingkup kecil.
Sementara itu, manajemen kode sumber mencakup kontrol versi tetapi juga melibatkan alur kerja dan bagaimana kode diatur. Manajemen ini lebih luas cakupannya, menyentuh fase yang berbeda dari siklus hidup pengembangan perangkat lunak (SDLC).
Manajemen kode sumber sangat penting untuk sebagian besar fase siklus hidup pengembangan perangkat lunak. SCM mempromosikan penanganan kode yang tepat saat mengalir di seluruh SDLC.
Tahap ini memerlukan penguraian desain proyek, yang juga termasuk memilih arsitektur repo dan menyiapkannya. Tim memetakan struktur awal untuk repositori berdasarkan komponen perangkat lunak, fitur atau tonggak yang ditentukan dalam dokumen desain atau dokumen spesifikasi persyaratan. Pembuatan prototipe dapat membantu tim memahami dan memvisualisasikan bagaimana kode sumber proyek dan file pendukung akan disimpan dan diatur.
Fase pengembangan adalah ketika cabang didirikan. Para pengembang menulis dan melakukan commit kode, kemudian membuat permintaan pull untuk menandai perubahan yang mereka sarankan agar ditinjau kodenya . Peninjau menilai perubahan sebelum menggabungkannya untuk menjaga kualitas kode.
SCM bekerja bersama dengan integrasi berkelanjutan (CI), bagian pertama dari pipeline CI/CD dan salah satu ciri metodologi DevOps. Ketika kode sumber didorong ke repo, server CI seperti CircleCI, GitHub Actions, GitLab CI/CD, dan Jenkins memicu proses pembangunan, sehingga mengotomatiskan kompilasi kode dan pengemasan. Alat CI menjalankan pengujian otomatis untuk memastikan perubahan tidak merusak basis kode dan mengidentifikasi masalah apa pun sebelum disebar ke bagian produksi.
Manajemen kode sumber terintegrasi dengan pengiriman berkelanjutan (CD), yang melanjutkan tempat yang ditinggalkan CI. Alat SCM membantu memastikan bahwa hanya versi kode sumber yang stabil dan valid yang digunakan, sementara alat CD mengotomatiskan pengiriman perubahan kode yang dapat diterapkan setelah melewati pengujian otomatis.
Melalui penerapan berkelanjutan, perubahan yang berhasil divalidasi secara otomatis diterapkan ke produksi. Jika penerapan gagal, semua sistem ini (SCM, CI/CD dan penerapan berkelanjutan) bekerja sama untuk memutar kembali dengan lancar ke versi stabil sebelumnya.
SCM memfasilitasi siklus yang lebih lancar untuk rilis mendatang. Ini merupakan bagian integral dari pengelolaan basis kode saat mereka berkembang dengan perbaikan bug, penyempurnaan, fitur baru, patch, pengoptimalan kinerja, pemfaktoran ulang, dan pembaruan lainnya.
Tetap terinformasi tentang tren industri yang paling penting—dan menarik—tentang AI, otomatisasi, data, dan di luarnya dengan buletin Think. Lihat Pernyataan Privasi IBM®.
Tim rekayasa perangkat lunak dapat memperoleh keuntungan ini dari sistem SCM:
Kontrol akses dan audit
Cadangan basis kode
Peningkatan kualitas kode
Kolaborasi yang Efisien
Rilis perangkat lunak Swift
Manajemen kode sumber dapat membatasi akses ke repositori, memastikan hanya pengguna yang diautentikasi dan berwenang yang diizinkan untuk membuat perubahan. Tindakan ini membantu melindungi IP organisasi dan terbukti sangat berharga untuk sektor-sektor seperti keuangan dan perawatan kesehatan, dengan terus mengutamakan pengamanan data sensitif.
Sistem ini juga membantu audit. SCM menyimpan riwayat versi lengkap dari semua perubahan kode, sehingga menghasilkan jejak audit yang jelas. Tindakan ini membantu pengembang dalam memahami apa yang diubah dan mengapa (melalui pesan commit), siapa yang mengimplementasikannya dan kapan mereka diterapkan, sehingga debugging jadi lebih mudah dan lebih cepat.
Beberapa alat SCM dan sistem kontrol versi menawarkan fungsionalitas untuk mencadangkan repo. Tindakan ini menyediakan cara untuk memulihkan basis kode jika terjadi kegagalan kritis atau gangguan mendadak, sehingga tim terselamatkan dari keharusan memulai dari awal.
Manajemen kode sumber merampingkan peningkatan kualitas kode. Permintaan pull bertindak sebagai pos pemeriksaan, memastikan commit disetujui sebelum digabungkan ke bagian utama. Sistem SCM juga dapat bekerja dengan linter untuk memeriksa masalah pemformatan atau gaya, alat analisis kode statis untuk menunjukkan kelemahan logis dan kesalahan sintaks, dan alat CI untuk melakukan pemindaian keamanan dan memastikan modifikasi kode lulus tes.
Dengan manajemen kode sumber, beberapa pengembang dapat berkontribusi pada proyek perangkat lunak. Mereka tidak perlu menunggu satu sama lain untuk menyelesaikannya sebelum memulai tugas mereka sendiri. Semua perubahan mereka digabungkan bersama pada akhirnya, dengan pengeditan yang saling bertentangan diselesaikan.
Tim terdistribusi yang tersebar di lokasi yang berbeda dapat membangun pekerjaan satu sama lain tanpa takut mengganti modifikasi mereka. Anggota dapat berbagi perubahan satu sama lain melalui permintaan tarik, sementara tinjauan sejawat menumbuhkan penyebaran pengetahuan dan umpan balik.
Melalui SCM, setiap anggota tim dapat bekerja secara terpisah namun bersamaan. Dan karena manajemen kode sumber terintegrasi dengan lancar dengan pipeline CI/CD, siklus pengiriman menjadi lebih cepat. Tim pengembangan dapat dengan cepat menanggapi masalah produksi dan merilis patch lebih cepat.
Salah satu iterasi paling awal dari alat SCM adalah Sistem Kontrol Kode Sumber (SCCS) yang dikembangkan oleh programmer komputer Bell Labs, Marc Rochkind, pada tahun 1970-an. SCCS memberlakukan mekanisme penguncian yang ketat, sehingga hanya satu orang pada satu waktu yang dapat memodifikasi file, dengan revisi disimpan sebagai salinan lengkap. Penerusnya, Sistem Kontrol Revisi (RCS), ditingkatkan pada SCCS, menjaga versi terbaru file tetapi hanya menyimpan perbedaan antara versi yang lebih lama.
Pada 1980-an, Sistem Versi Bersamaan (CVS) muncul. Sistem ini dibangun di atas RCS dan mengikuti model repo klien-server yang memperkenalkan konkurensi dan penggabungan.
Subversi (SVN) muncul pada awal 2000-an dengan tujuan menjadi “CVS yang lebih baik.” Sistem ini mempertahankan banyak fungsi CVS tetapi menambahkan fitur seperti commit atomik dan direktori berversi. Secara resmi dikenal sebagai Subversi Apache, sistem ini saat ini dikelola sebagai proyek sumber terbuka oleh Apache Software Foundation dan terus digunakan secara luas.
Pada pertengahan 2000-an terlihat kemunculan sistem kontrol versi terdesentralisasi. Pencipta Linux Linus Torvalds memimpin pengembangan Git, sebuah sistem kontrol versi terdistribusi sumber terbuka yang awalnya dibuat untuk kernel Linux. Alih-alih menyimpan file dan modifikasinya, Git menyimpan snapshot status proyek dari waktu ke waktu. Sistem ini dapat digunakan sendiri dengan menjalankan perintah Git pada baris perintah, tetapi juga memiliki ekosistem alat yang kaya, termasuk GUI dan integrasi IDE.
Git berfungsi sebagai dasar untuk beberapa alat manajemen kode sumber paling populer saat ini, termasuk Bitbucket, GitHub, dan GitLab. Tetapi dengan agen AI yang sekarang menghasilkan kode dalam jumlah besar, beberapa perusahaan kembali mempertimbangkan SCM. Misalnya, Origin Cursor menyebut dirinya sebagai “git forge untuk era agen,” sementara DeltaDB Zed menautkan perubahan kode ke percakapan agen yang menghasilkannya. Demikian pula, GitLab sedang mengerjakan apa yang disebutnya sebagai "manajemen kode sumber generasi berikutnya" untuk armada agen pengodean.
Percepat penyediaan perangkat lunak dengan IBM Bob, mitra AI Anda untuk pengembangan yang aman dan sadar tujuan.
Kembangkan, terapkan, dan kelola aplikasi AI lebih cepat dengan alat yang siap untuk perusahaan.
Menata ulang sistem lama dengan modernisasi AI cerdas.