Adakah perusahaan serius yang tidak menggunakan kontrol versi dan integrasi berkesinambungan? Mengapa?


17

Seorang kolega saya mendapat kesan bahwa departemen perangkat lunak kami sangat maju, karena kami menggunakan server pembangun dengan integrasi berkelanjutan, dan perangkat lunak kontrol versi. Ini tidak sesuai dengan sudut pandang saya, karena saya hanya tahu satu perusahaan saya yang membuat perangkat lunak serius dan tidak memilikinya. Namun, pengalaman saya hanya terbatas pada segelintir perusahaan.

Adakah yang tahu perusahaan sungguhan (lebih dari 3 programmer) , yang ada di bisnis perangkat lunak dan tidak menggunakan alat ini? Jika perusahaan semacam itu ada, adakah alasan bagus bagi mereka untuk tidak melakukannya?


3
Para aktor perangkat lunak sial itu.
Lightness Races dengan Monica

1
apakah pelaku perangkat lunak berbeda dari pengembang perangkat lunak?
Aditya P

"Aku bukan perangkat lunak tapi aku memainkannya di TV !!" - Aktor perangkat lunak.
FrustratedWithFormsDesigner

1
Ada Jayne Seymour, dia seorang aktris perangkat lunak yang serius .... atau setidaknya dia bermain Solitare di Live and Let Die :)
Kevin D

3
Di mana saya bekerja sepuluh tahun yang lalu, kami membangun malam pada semua sistem yang didukung. Mereka tidak pernah mendekati kompilasi. Pernah.
David Thornley

Jawaban:


5

Saya tidak yakin Anda akan menyebut mereka tindakan serius, tetapi MySpace sangat buruk dalam hal ini: Lihat http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .


1
+1 Mereka setidaknya berada di liga utama. Saya tidak berpikir itu mungkin. Perusahaan besar tanpa kontrol versi. Sosok pergi.
daramarak

Gila. Saya tidak akan mempercayainya, tetapi blog dan referensi dari artikel tersebut semuanya dapat diandalkan.
Steve

Menyalahkan anjing.
JeffO

2
Situs web untuk remaja yang memulai sebuah band di garasi ditulis dengan gaya seorang pembuat kode yang bekerja di garasi mereka. Tokoh
quant_dev

13

Anda akan terkejut melihat apa yang bisa dilakukan oleh realitas dengan akal sehat ;-)

Saya pikir masih ada beberapa perusahaan di luar sana yang tidak menggunakan sistem kontrol versi. Menariknya dalam semua kasus yang saya lihat sejauh ini bukan karena mereka dengan sukarela menentang penggunaan sistem seperti itu tetapi karena mereka tidak tahu bahwa sesuatu seperti SVN ada! Bagi saya: Saya sepenuhnya setuju dengan Anda dan tidak dapat membayangkan situasi di mana saya tidak ingin menggunakan kontrol versi apa pun. Sial, saya bahkan mendorong file pribadi saya sendiri (dokumen kata, dll.) Di PC rumah saya ke repositori GIT.

Dalam hal sistem integrasi berkelanjutan, sedikit lebih umum untuk tidak menggunakan mereka dalam operasi sehari-hari. Kadang-kadang juga karena orang-orang tidak tahu sistem seperti itu ada tetapi saya juga telah melihat kasus-kasus di mana - sangat dipertanyakan - alasan untuk tidak menggunakannya adalah bahwa "kami tidak cukup kompleks" atau "itu bekerja dengan sangat baik tanpa integrasi terus menerus, jadi mengapa repot-repot menambahkan teknologi lain? " Tentu saja itu tidak berdiri evaluasi realistis - tetapi untuk menjawab pertanyaan awal: Ini tidak semua yang biasa.


11
Mungkinkah pengembang perangkat lunak biasa belum mendengar tentang perangkat lunak kontrol versi? Dari mana perusahaan-perusahaan ini mempekerjakan orang? Sisi gelap bulan?
daramarak

7
@daramarak: Banyak pengembang perangkat lunak (jika tidak sebagian besar) tidak membaca buku, tidak menelusuri blog pengembangan, dan sama sekali tidak berkomunikasi dengan pengembang lain (di luar perusahaan mereka). Jika Anda masuk dalam pengembangan dengan mengajar diri Anda sendiri dengan salah satu dari buku-buku "belajar visual dasar dalam 21 hari", maka Anda tidak akan mendengar tentang kontrol versi. Bahkan, saya tidak ingat belajar tentang kontrol versi di universitas, hanya 10 tahun yang lalu.
Joeri Sebrechts

@ Joeri - untungnya tidak benar di tempat saya bekerja, tapi saya bisa percaya secara umum.
Steve

@perdian - Anda mengatakan "cukup banyak perusahaan" tetapi tidak memberikan spesifik ... apakah Anda memiliki tautan ke artikel, blog, dll, penamaan dan mempermalukan? Saya tidak mengatakan saya tidak percaya Anda (sebenarnya saya tidak percaya Anda), namun data selalu baik ...
Steve

@Steve Haigh - Tidak, saya tidak punya bukti "keras". Saya telah melihat beberapa perusahaan sendiri yang tidak menggunakan kontrol versi CI oder (yang namanya akan saya simpan sendiri g ) dan dengan sedikit ekstrapolasi saya berasumsi bahwa ada lebih banyak "di luar sana". Saya pikir itu adalah easiert banyak untuk menemukan perusahaan yang melakukan penggunaan CI, hanya dengan melihat daftar referensi di halaman Jenkins misalnya. Tetapi sebaliknya? Tidak banyak orang yang mengiklankan "Hei, kami tidak menggunakan teknologi X" ;-)
perdian

12

Hampir setiap perusahaan di industri saya (perbankan) saat ini menggunakan kontrol versi. Tetapi tentu saja mungkin untuk mengembangkan perangkat lunak dengan sukses tanpa kontrol versi. 20-30 tahun yang lalu. kami melakukan itu.

Saya akan mengatakan banyak bank, bahkan mungkin mayoritas, tidak menggunakan server build dengan integrasi berkelanjutan. Jika Anda telah mengirimkan perangkat lunak dengan sukses tanpa integrasi berkesinambungan, sangat masuk akal untuk melanjutkannya.


3
Saya tidak setuju bahwa itu sangat rasional untuk "melanjutkan jalan itu". Ya, memiliki perangkat lunak yang dikirim selama X tahun terakhir tidak berarti tidak akan berfungsi selama Y tahun berikutnya tanpa perubahan apa pun. Namun, setelah memperkenalkan CI ke dalam produk perangkat lunak yang ada (dan cukup matang) selalu ada sesuatu yang dapat diperoleh dari ini.
perdian

1
@perdian: selalu ada yang bisa didapat dari banyak inisiatif. Jadi, Anda harus menyeimbangkan CI terhadap yang lainnya. Anda tidak bisa hanya mengklaim bahwa CI memberi Anda lebih banyak manfaat daripada yang lainnya. Anda juga harus mengukur biaya peluang.
RoadWarrior

1
@ SK-logic: RCS benar-benar tidak dikenal pada saat itu di industri perbankan Inggris. Dan kami mengembangkan beberapa sistem yang sangat besar dan kuat tanpa kendali sumber apa pun.
RoadWarrior

1
-1: "Hampir setiap perusahaan" itu pernyataan yang terlalu luas yang salah. Saya telah melihat dalam beberapa tahun terakhir beberapa perusahaan yang tidak menggunakan alat kontrol versi apa pun, mengandalkan salinan versi pada direktori bersama. Ya, ini membuatku menangis. Mereka mengatakan bahwa "svn terlalu sulit untuk digunakan". OH TUHAN. Tetapi saya masih menemukan beberapa perusahaan yang seperti itu. Jangan menyamaratakan, tidak semua orang di industri tahu apa itu sistem kontrol sumber, juga tidak belajar apa pun secara online, juga tidak tahu apa itu integrasi berkelanjutan. (Saya setuju itu neraka. Senang tidak ada lagi di sana).
Klaim

1
@ SK-logic - ... apa yang dinyatakan RoadWarrior, kecuali di industri kelautan / listrik di sini. Saya tidak akan memberikan nama, tetapi tahu setidaknya dua perusahaan yang dominan di sektor mereka (beberapa pengembangan perangkat lunak khusus) yang saya percaya tidak pernah menggunakan VCS dalam bentuk apa pun (dalam pengertian Anda). Mereka memiliki cara mereka membedakan kode yang baik dari kode yang sedang berjalan.
Benteng

7

Hanya untuk menunjukkan poin counter ke jawaban @ RoadWarrior:

Saya bekerja untuk Bank. Saya telah menghabiskan 3 tahun terakhir untuk menerapkan kontrol versi dan sekarang berhasil mendapatkan sekitar 20% dari basis kode kami (yang cukup besar, kami memiliki sekitar 20 pengembang dan telah mengembangkan sistem kami selama> 16 tahun)

Melalui kontak saya di industri (Perbankan), saya tahu satu ton lembaga keuangan lain yang tidak memiliki apa yang orang waras sebut kontrol versi.

Ya, industri kami (Pengembangan Perangkat Lunak) jauh lebih sedih daripada yang ingin sebagian besar orang akui.


Belasungkawa. Kedengarannya seperti setidaknya beberapa bagian dari industri ini sangat kekurangan alat. Saya kira ini adalah cerita tentang anak-anak tukang sepatu lagi. Bisakah saya bertanya apa yang orang gila sebut kontrol versi?
daramarak

6
Mengambil salinan kode secara manual sebelum Anda mengeditnya. Misalnya, MyProg -> MyProd.old4
Dan McGrath

Sayangnya praktik ini lebih umum daripada yang dipikirkan orang
Craig T

3

kontrol versi: Dalam pekerjaan pertama saya 25 tahun yang lalu tidak ada sistem kontrol versi seperti itu, tapi ini RSX11 pada PDP-11s. Namun, ada tingkat kontrol kualitas yang sangat tinggi dengan tinjauan formal desain dan kode (ini ada di industri nuklir).

Setiap pekerjaan sejak itu telah menggunakan sistem kontrol versi, termasuk SCCS, PVCS, clearcase, cvs dan terpaksa.

Jadi dalam pengalaman saya penggunaan kontrol versi cukup universal dalam pengembangan perangkat lunak yang serius.

integrasi berkelanjutan: Ini lebih merupakan masalah, terutama di tempat-tempat yang memiliki banyak kode warisan yang mungkin bahkan tidak memiliki banyak cara pengujian otomatis. Dibutuhkan investasi yang sangat besar untuk memindahkan kode yang ada ke lingkungan CI, dan meskipun mungkin terbayar pada akhirnya, sulit untuk membuat manajemen berkomitmen untuk investasi semacam itu tanpa keuntungan jangka pendek.

Saya telah bekerja di satu tempat (bank besar) yang memiliki CI di beberapa proyek, dan kami menerapkan semacam sistem CI pada proyek kami yang memang membuat segalanya jauh lebih mudah, tetapi membutuhkan waktu sekitar 6 bulan untuk melakukannya.


Untuk tempat-tempat dengan kode lawas, apakah mereka melakukan pembangunan otomatis, atau apakah mereka memiliki rencana pembangunan / penempatan manual?
daramarak

3

Saya akan membayangkan bahwa sebagian besar perusahaan tidak menggunakan hal-hal ini, karena mereka tidak memahami manfaatnya dan pengembang mereka tidak mau belajar atau takut untuk "mengaduk-aduk panci" dengan melakukan hal-hal yang berbeda dengan bagaimana mereka telah dilakukan sebelumnya.


3
Benar! Saya sudah mendengar jawabannya (atau mungkin kita harus menyebutnya alasan lumpuh) "kami belum menggunakannya sejauh ini dan karena itu berhasil (entah bagaimana) kami tidak membutuhkannya". Sangat memalukan bagaimana orang yang ulet menentang mengubah alat mereka.
perdian

1
Saya tidak tahan orang seperti itu; sayangnya itu adalah jenis "pengembang" yang saya temui terlalu sering dalam karier saya, dan saya tidak bisa mengatasi ketidaktahuan mereka dan selalu terlihat meninggalkan perusahaan di mana jenis-jenis pengembang itu lazim. Dengan risiko terdengar sangat bermusuhan, orang-orang semacam itu adalah kanker pada profesi ini.
Wayne Molina

2

Meskipun saya seorang karyawan sekarang, saya dulu bekerja sendiri sebagai konsultan basis data. Selama bertahun-tahun itu, saya berada di suatu tempat antara 800 dan 1000 perusahaan, dari level ibu-dan-pop hingga Fortune 100-an.

Saya melihat relatif sedikit tempat yang melakukan integrasi terus-menerus, tetapi saya tidak ingat pernah melihat perusahaan yang tidak menggunakan kontrol versi. Saya memang melihat beberapa di mana tidak ada repositori terpusat untuk kode yang dikontrol versi. Masing-masing programmer menggunakan kontrol versi di komputer mereka sendiri atau menyimpan kode yang dikontrol versi di suatu tempat di bawah direktori home mereka di server.

Saya tidak berpikir ada dari perusahaan - perusahaan ini dalam bisnis perangkat lunak, tetapi programmer mereka tentu saja.


1

Seorang kolega saya mendapat kesan bahwa departemen perangkat lunak kami sangat maju karena kami menggunakan server pembangun dengan integrasi berkesinambungan, dan perangkat lunak kontrol versi.

Tidak saya benci mengatakannya, tetapi ini benar. Dua tempat terakhir saya bekerja (sebuah divisi dari sebuah bank, dan sebuah perusahaan keuangan), saya adalah orang yang menerapkan sistem kontrol versi. Sejumlah tempat (terutama toko-toko non-perangkat lunak) tidak mengerti mengapa itu benar-benar diperlukan untuk pengembangan jangka panjang. Tim biasanya dimulai sebagai satu atau dua orang dan kemudian tumbuh dari sana, meskipun menyakitkan. Dengan satu atau dua orang, Anda dapat bertahan (tidak baik) tanpa itu karena Anda dapat berkomunikasi hampir konstan satu sama lain.

Pembangunan berkelanjutan adalah kasus yang sama sekali berbeda. Jika saya harus menebak saya berani bertaruh bahwa hampir 90% tempat di mana pengembangan dilakukan tidak memiliki solusi CI di tempat. Saya pergi ke konferensi dan kebanyakan orang kagum bahwa organisasi selain MS atau Google memilikinya. Apa yang saya temukan adalah bahwa manajemen tidak ingin menghabiskan sejumlah kecil uang untuk menjalankan dan menjalankannya meskipun itu dapat menghemat banyak waktu.

Alasan terbesar yang saya temukan untuk ini adalah:

  1. Orang-orang dalam manajemen telah naik melalui jajaran di organisasi yang sama. Mereka tidak pernah menggunakan dan tidak membutuhkannya, mengapa mereka harus berubah sekarang? Beberapa yang saya temukan hanya takut akan perubahan. Sesuatu yang baru menakutkan, dan itu akan mencegah mereka membersihkan kompiler lama mereka dan membantu kami yang lebih muda pada saat dibutuhkan. Di waktu lain (dan lebih sering), mereka memiliki anggaran yang selalu ketat, dan mereka harus membuat keputusan tentang di mana harus mengeluarkan uang. Bagi kami menerapkan ini adalah kebutuhan yang jelas, tetapi itu karena kami telah menggunakannya sebelumnya. Kami tahu manfaatnya, mereka tidak.

  2. Manajer adalah orang-orang non-IT, dan yang mereka miliki di sini adalah Anda ingin membelanjakan uang untuk sesuatu yang belum dibutuhkan sebelumnya.

Sebagian besar argumen yang saya dengar dari orang-orang berpusat pada praktik-praktik terbaik, dll. Dan itu benar, tetapi yang paling tidak dipahami oleh para dev adalah bahwa Anda harus membingkainya dalam situasi keuangan ketika dalam skenario ini. Dengan jumlah uang yang akan Anda belanjakan, kami akan menghemat jumlah waktu X, dan Anda perlu angka untuk mendukungnya. Ini tidak selalu benar, tetapi telah menjadi pengalaman saya di masa lalu.


Saya bisa membayangkan bahwa masalah seperti ini muncul ketika ada komunikasi yang buruk dari pengembang dan ke atas dalam manajemen. Untungnya tidak semua perusahaan seperti ini. Di tempat saya bekerja, kita diharapkan (jika tidak berkewajiban) untuk memberi tahu manajemen jika ada yang bisa membuat kita lebih efektif.
daramarak

1

Saya akan mengatakan banyak orang tidak menggunakan kontrol sumber karena mereka dapat mengkode sendiri dan digunakan untuk membuat cadangan basis kode ke server pusat atau hard drive USB secara berkala. Saya memaksa diri sekitar setahun yang lalu untuk mulai menggunakan SVN karena saya tahu itu akan bermanfaat dalam jangka panjang. Butuh beberapa saat untuk membiasakan diri tetapi sekarang saya memiliki banyak sejarah kode yang dapat saya rujuk secara konstan. Saya berharap sekarang bahwa saya telah menerapkannya empat tahun lalu ketika saya mulai.

Integrasi berkelanjutan? Hanya gunakan jika Anda membutuhkannya. Bagi saya, hanya ada dua insinyur perangkat lunak sehingga kami tidak akan mendapat manfaat dari integrasi berkelanjutan karena kami mengerjakan sendiri perangkat lunak kami.


1
Integrasi berkesinambungan seharusnya mengidentifikasi kesalahan ketika terjadi. Bahkan dua pengembang membutuhkan itu.
daramarak

1
@ Daramarak: Tidak jika kedua insinyur bekerja secara independen pada dua produk terpisah yang tidak terintegrasi.
Brian

1
CI adalah salah satu hal yang saya bersedia lakukan tanpanya. Secara pribadi saya ingin memilikinya dalam pekerjaan saya, tetapi itu tidak akan terjadi dalam waktu dekat. Kami memiliki build otomatis 1-2 kali sehari, dan itu sudah cukup untuk kebutuhan kami.
Michael K

1
Dengan bangunan otomatis, Anda berada di tengah jalan. Hanya mengetahui bahwa segala sesuatu yang diperiksa dalam kompilasi kadang-kadang bisa menjadi kegembiraan ("Ini mengkompilasi pada komputer saya")
daramarak

1

Ha, Anda pikir Anda sudah maju karena Anda memiliki sistem SCM dan CI? Izinkan saya memberi tahu Anda bahwa saat itu adalah jam amatir.

Banyak perusahaan melakukan persyaratan minimum, karena hanya itu yang benar-benar dibutuhkan . Jika berhasil, dan Anda mendapatkan rilis yang dapat direproduksi dengan baik tanpa upaya besar, maka tidak ada yang perlu diperbaiki. Hal terakhir yang ingin Anda lakukan dalam keadaan seperti itu adalah mulai 'memperbaiki' hal-hal, terutama ketika mengambil sumber daya admin dari pekerjaan mereka untuk mengatur dan mengelola server baru Anda dan membangun sistem.

Namun, beberapa perusahaan memerlukan sistem yang sedikit lebih ketat, sekali yang tidak hanya membangun, tetapi mengontrol persyaratan sampai ke penyebaran melalui rencana pengujian dan hasil pengujian, mengambil tinjauan kode, prosedur checkin alur kerja-gaya dan manajemen paket kerja yang ditunjuk oleh pemimpin tim. Itu manajemen konfigurasi yang nyata, dan sangat senang Anda tidak perlu bekerja di lingkungan seperti itu!

Saya telah bekerja di beberapa perusahaan, dan saya tidak dapat memikirkan yang tidak memiliki bentuk SCM. Beberapa dari mereka lebih komprehensif daripada yang lain, tetapi mereka semua memiliki sistem yang bekerja dengan baik untuk mereka, bahkan yang menggunakan VSS.


lol! ditandatangani: seorang profesional.
deadalnix

Saya setuju, SCM dan pelacak bug adalah pengembangan yang setara dengan memakai celana untuk bekerja. CI adalah otomatisasi dasar dari fungsi kritis. Seperti backup otomatis tetapi untuk rilis. Ah, pertemuan CCB. Setiap minggu, seperti jarum jam.
Tim Williscroft

1

Bahkan dengan dua programmer ketika Anda mengerjakan aplikasi yang kompleks dan daftar tugas, akan sulit untuk tidak saling memalu perubahan satu sama lain.

Bahkan perangkat lunak manajemen rilis lama kami menunjukkan perubahan secara berdampingan dan memungkinkannya untuk diterapkan di kedua arah. Perubahan akan terlewatkan pada lebih dari satu kesempatan tanpanya.

Saya melihat sejumlah manfaat yang datang dari CI tetapi saya tidak dapat membayangkan mengapa perusahaan mana pun tidak menggunakan perangkat lunak kontrol versi.


1

Pekerjaan terakhir yang saya kerjakan tanpa kontrol versi adalah pada tahun 2006 (saya seorang pengembang Web, FWIW). Perusahaan ini hanya memiliki sekitar 2 atau 3 pengembang sebelum mempekerjakan saya, tetapi saya adalah yang pertama dari 10 atau lebih pengembang yang dipekerjakan hanya dalam beberapa bulan. Salah satu hal pertama yang saya lakukan ketika dipekerjakan adalah memperkenalkan kontrol versi (CVS, karena saya tidak tahu pada saat itu betapa buruknya hal itu!), Tetapi banyak pengembang yang dipekerjakan setelah saya tidak dapat membuatnya bekerja pada perangkat mereka. lingkungan, jadi tidak menggunakannya. Oh, apakah saya menyebutkan bahwa mereka bahkan tidak memiliki instance lokal dari aplikasi yang berjalan? Mereka meretas kode di server. Dan tidak ada tes otomatis, tentu saja. Saya merasa ngeri ketika saya mengingatnya kembali.

Sebelum itu, saya melakukan beberapa pekerjaan pemrograman AS / 400 tanpa kontrol versi. Saya tidak tahu apakah VCS yang layak bahkan tersedia untuk lingkungan itu.

Sekarang saya menggunakan Git untuk semua proyek one-man saya, dan beberapa pekerjaan terakhir saya juga menggunakannya.

CI adalah masalah yang berbeda. Ini bagus untuk dimiliki, dan saya mendorongnya, tetapi ini kurang penting daripada kontrol versi, setidaknya untuk proyek yang lebih kecil dalam bahasa yang ditafsirkan. Namun, sebagian besar pekerjaan saya baru-baru ini memiliki server CI; antara lain, itu berarti bahwa tidak ada yang bisa lupa untuk menjalankan test suite lengkap sebelum penggelaran.


'CI adalah masalah yang berbeda. Sangat bagus untuk dimiliki, dan saya mendorongnya, tetapi ini kurang penting daripada kontrol versi, setidaknya untuk proyek-proyek kecil dalam bahasa yang ditafsirkan. ' Sepakat. CI benar-benar hanya diperlukan ketika Anda melakukan pembangunan yang sering dan / atau kompleks dan itu mulai memakan banyak waktu Anda, atau Anda ingin menjalankan test suite, atau Anda ingin dapat mem-stage beberapa cabang, dll. Jika itu sebuah proyek PHP dengan selusin pengembang, tidak ada test suite, dan Anda mendorong produksi sekali seminggu, Anda mungkin ingin fokus pada alur kerja QA yang baik sebelum Anda mulai mengkhawatirkan CI.
siliconrockstar

Dan Anda mungkin ingin fokus pada test suite yang baik sebelum Anda mulai khawatir tentang QA, atau apa pun.
Marnen Laibow-Koser

Mungkin secara teori, tetapi jika Anda menggunakan perangkat lunak open source, kecuali itu dikirim dengan test suite, ini praktis tidak mungkin. Saya belum pernah bekerja pada proyek PHP yang memiliki cakupan tes lengkap yang tepat, tetapi setiap proyek yang saya kerjakan memiliki tingkat QA tertentu.
siliconrockstar

@ siliconrockstar Saya sedang berbicara tentang memiliki suite tes yang baik untuk kode Anda sendiri; tingkat pengujian kode perpustakaan yang tepat adalah masalah lain.
Marnen Laibow-Koser

@siliconrockstar Untuk apa nilainya, sebagian besar proyek Rails yang saya kerjakan memiliki cakupan uji pengembang yang sangat baik (pengecualian secara aktif mencoba untuk memperbaikinya); tidak semua memiliki QA formal. Jauh lebih tidak perlu memiliki QA formal dengan tes yang baik, meskipun itu masih ide yang sangat bagus. Namun, pengembangan tanpa tes di tempat sangat berisiko, jadi itu sebabnya saya mengatakan bahwa peningkatan tes harus diprioritaskan daripada yang lainnya.
Marnen Laibow-Koser

0

Saya pasti bertemu dengan beberapa di sana-sini, tetapi kebanyakan perusahaan kecil. Masalah yang saya lihat lebih sering adalah perusahaan yang sebenarnya memiliki SCM, tetapi menganggap banyak proyek terlalu kecil atau tidak penting untuk dilacak di dalamnya.

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.