Saya bekerja di lembaga pemerintahan. Teknologi yang digunakan di sini dan metode untuk mengembangkan perangkat lunak cukup kuno.

Mereka memiliki banyak ruang penyimpanan tetapi tidak ada ruang yang sesuai untuk menyimpan dan memelihara aplikasi yang digunakan untuk mengotomatisasi sebagian besar pekerjaan di sini.

Institusi tidak mengizinkan saya untuk menggunakan perangkat lunak SCM seperti GIT atau SVN.

Apa yang akan menjadi pendekatan terbaik untuk menjaga kualitas kode dan dapat menambahkan fitur baru di aplikasi nanti?

Bagaimana saya bisa mengingat perubahan yang saya buat pada kode tanpa merusaknya?

EDIT: Saya lupa menyebutkan, mereka memiliki drive jaringan untuk masing-masing komputer dan entah bagaimana drive jaringan ini membuat atau menyimpan cadangan dalam periode. Namun jika saya tidak membuat rencana saya sendiri yang memungkinkan untuk menyimpan pekerjaan saya dan dapat menambahkan fitur baru tanpa melanggar kode yang ada, tidak ada keuntungan besar dari solusi SCM.

EDIT: Karena banyak orang menyarankan portable Git saya harus menambahkan lebih banyak info. Saya mencoba menginstal server Visual SVN, tetapi gagal karena saya tidak memiliki hak admin untuk menginstal. Saya juga mencoba mengunduh Git shell biasa, tetapi firewall atau pengaturan jaringan tidak memungkinkan saya untuk mengakses halaman unduhan Git. Saya bahkan mencoba, mengirim Git portabel ke email saya yang merupakan Gmail. Google mendeteksi file exe dalam paket, dan itu juga tidak memungkinkan saya untuk mengunduh versi Git portabel di komputer kerja saya. Hal lain yang harus saya sebutkan, kebijakan jaringan yang diterapkan pada komputer melalui lembaga tidak memungkinkan menggunakan devces penyimpanan USB. Anda dapat menggunakan port USB untuk mengisi daya ponsel cerdas atau memberi daya pada beberapa gadget seperti pengeras suara kecil. Juga seperti yang disebutkan beberapa orang, ada komputer yang bahkan Internet tidak diperbolehkan.

Anda dapat dengan mudah meniru permainan kontrol sumber peran dengan tiga alat sederhana:

• Perangkat lunak cadangan (Komit / Check-in)
• Folder (Cabang)
• Melakukan penggabungan direktori antara dua direktori menggunakan alat seperti KDiff3 (Menggabung cabang)

Pada dasarnya alur kerja Anda menjadi:

1. Buat folder baru (cabang baru)
2. Salin file ke folder baru (cabang baru) dari folder yang ada (cabang yang ada)
3. Buat cadangan folder itu (selesai membuat cabang baru)
4. Lakukan beberapa pekerjaan
5. Buat cadangan folder baru (komit)
6. Melakukan penggabungan direktori dari satu folder ke folder lainnya (gabungan)
7. Lakukan cadangan lain di folder lain (komit gabungan)

Sistem kontrol sumber yang lebih monolitik, seperti SVN atau TFS, pada dasarnya melakukan ini untuk Anda di belakang layar.

Sekarang, kenyataannya adalah ini seperti Perusahaan Bus mengatakan kepada pengemudi bahwa mereka tidak dapat mengendarai bus yang memiliki baterai, memaksa pengemudi untuk mendorong bus turun bukit dan kemudian melepaskan kopling untuk memulai bus ... ini mengerikan dan menunjukkan bahwa manajemen saat ini tidak tahu apa-apa tentang menjalankan garasi bus. Belasungkawa.

Tapi setidaknya Anda bisa memulai bus.

Meskipun konsensus pasti untuk tidak bekerja untuk perusahaan ini, saya tidak percaya itu benar-benar menjawab pertanyaan Anda.

Anda tidak dapat benar-benar mengganti SCM .

Anda mungkin tidak membutuhkan bel dan peluit biasa dari sistem full-blown. Misalnya, perusahaan dapat menolak permintaan untuk server, tetapi mengizinkan penggunaan SCM lokal. Mereka mungkin tidak menyukai git, tetapi mengizinkan subversi (atau sistem versi lain).

Tentu saja ada pertanyaan: apa yang digunakan kolega Anda, atau pekerja sebelumnya? Jika Anda adalah Pengembang Perangkat Lunak pertama yang mereka miliki, maka sudah saatnya Anda mendorong sangat keras untuk sumber daya yang Anda butuhkan.

Pada akhirnya, jika perusahaan Anda tidak menghargai peran dan pengalaman Anda dan tidak akan mengizinkan Anda alat yang Anda butuhkan, maka Anda akan mengalami masalah yang lebih buruk (dan lebih membuat stres) daripada kurangnya kontrol sumber.

Pada dasarnya, ada masalah manajemen (organisasi Anda tidak memahami dasar-dasar proses pengembangan perangkat lunak , misalnya model-V ) yang mengembun menjadi ketidakmampuan menggunakan alur kerja, metodologi, dan alat minimal era sekarang. Ini umum (baca tentang prinsip Peter ).

^{BTW, saya kira insiden kereta SNCF baru-baru ini di Paris pada akhir 2017 memiliki penyebab yang sama (total kurangnya budaya perangkat lunak pada tingkat manajemen tinggi, maka penyumbatan stasiun kereta api utama Paris selama lebih dari satu hari; tentu saja ada sangat kompeten Tim TI di SNCF, tetapi mereka tidak diajak berkonsultasi tentang keputusan besar). Saya dapat menyebutkan beberapa industri di Eropa yang sama sekali tidak memiliki budaya perangkat lunak dan saya yakin dapat menemukan hal serupa bahkan di AS.}

Masalah utamanya adalah: apakah Anda bekerja sendiri di basis kode Anda, atau apakah Anda bekerja dengan rekan kerja?

Jika Anda bekerja sendiri, Anda dapat menggunakan git secara lokal di komputer Anda, dan membuat cadangan kode Anda (dan mungkin bahkan .gitrepositori Anda ) secara berkala (ke ruang penyimpanan eksternal). Pastikan untuk tidak pernah kehilangan lebih dari setengah hari kerja (jadi cadangkan data Anda secara berkala dan andal).

^{(Saya kira Anda tahu paling tidak keduanya gitdan svndan Anda tahu keunggulan teknis git; jika Anda bahkan tidak diizinkan menginstal beberapa alat seperti gitpada komputer kerja Anda, Anda perlu melakukan pembicaraan serius dengan bos Anda tentang masalah itu: Anda perlu kemampuan dan otorisasi untuk menginstal alat sumber terbuka eksternal (dan itu sesuai dengan tanggung jawab Anda untuk memilih, mengonfigurasi dan menginstalnya dengan bijak & hati - hati dan tanpa kerentanan yang diketahui )}

Jika Anda bekerja dengan beberapa rekan kerja (saya kira kurang dari selusin dari mereka), Anda perlu meyakinkan mereka semua untuk menggunakan sistem kontrol versi, dan Anda mungkin perlu memberi tahu hal itu kepada atasan langsung Anda (dan bos umum). Dia dapat (mungkin) memutuskan (atau secara implisit menerima) bahwa beberapa mesin (mungkin bahkan beberapa desktop lama, bahkan mungkin desktop Anda sendiri) digunakan sebagai server git. Anda benar-benar perlu mengatur server itu sehingga repositori git didukung setidaknya setiap jam; Anda tidak mampu (dan Anda perlu berbicara dengan bos Anda tentang) kehilangan lebih dari satu jam kerja tim Anda.

^{BTW, saya suka Linux, dan saya akan merekomendasikan menginstal Linux pada mesin yang bertindak sebagai gitserver; kemudian menginstal gitdan mengkonfigurasi cadangan berkala (dengan beberapa crontabpekerjaan) sangat mudah; perhatikan bahwa gitserver dapat menjalankan Linux dengan klien Windows yang menggunakannya. Saya bahkan menyarankan Anda untuk mengganti mesin pengembangan Anda ke Linux jika Anda bisa. Itu "lebih murah" dan jauh lebih ramah-pengembang}

Tetapi Anda perlu menggunakan SCM. Anda mungkin mengajukan pertanyaan yang berbeda kepada bos Anda: haruskah tim Anda menggunakan SCM yang ada atau haruskah menciptakan kembali roda dan membuat SCM Anda sendiri? Atasan umumnya menentang gagasan menciptakan kembali roda. Jika Anda diizinkan untuk menemukan kembali roda, beri tahu atasan Anda bahwa itu adalah pekerjaan penuh waktu selama setidaknya satu tahun (yang mungkin akan membuat bos Anda menangis, lalu terima cara yang jelas) dan bersenang-senang membuat SCM Anda sendiri. Dalam kasus yang tidak biasa itu, pastikan untuk mempelajari sistem SCM yang ada , dan minta untuk membuat sistem SCM Anda beberapa perangkat lunak gratis (untuk digunakan dan ditingkatkan oleh tim lain).

Anda mungkin perlu mempersiapkan (selama beberapa hari) yang tepat dan spesifik argumentasi untuk kebutuhan sebuah SCM : pertama bagi rekan-rekan Anda, maka untuk atasan langsung Anda. Pastikan juga menyarankan solusi konkret (seperti menjalankan beberapa server git pada desktop atau server "lama", dan mencadangkannya setiap jam melalui crontabpekerjaan)

Jangan memasang perangkat lunak apa pun (dari luar, bahkan sumber terbuka) di komputer kantor Anda tanpa izin (di sebagian besar negara, terutama untuk pekerjaan IT sensitif bagi Negara, menginstal perangkat lunak tanpa izin secara hukum merupakan kejahatan, dan Anda mungkin kehilangan pekerjaan atau masuk penjara jika Anda melakukan itu .... jadi pastikan untuk diizinkan melakukannya, mungkin tutupi pantat Anda dengan meminta izin secara tertulis, atau setidaknya melalui email).

^{(baik Anda harus bertanya pada kasus per kasus, atau Anda perlu untuk mendapatkan kepercayaan dari organisasi Anda akan diizinkan untuk menginstal hukum software -mostly open source atau dengan peranti lunak gratis di komputer kerja Anda).}

PS. Bagaimana secara teknis membangun, mengkonfigurasi, menginstal kemudian menggunakangit (dari kode sumber perangkat lunak gratis) -atau sebagian besar perangkat lunak bebas lainnya VCS- pada mesin (bahkan tanpa izin admin) adalah pertanyaan yang sangat berbeda (untuk ditanyakan di tempat lain). Dan dimungkinkan untuk menginstal kemudian menggunakan gittanpa izin admin, asalkan Anda memiliki sumber daya yang cukup (waktu, ruang disk, beberapa kompiler C, dll ...) untuk itu.

Saya mencoba menginstal server Visual SVN, tetapi gagal karena saya tidak memiliki hak admin untuk menginstal.

Ini dipecahkan oleh beberapa konfigurasi khusus dan kompilasi Anda gitatau svndari perangkat lunak bebas kode sumber gitatau Subversion -tidak hanya paket-biner (dan juga kode sumber dari dependensi ); bagaimana melakukannya secara teknis adalah pertanyaan yang berbeda (tetapi pertanyaan teknis semacam itu harus pergi ke tempat lain ). Tentu saja Anda harus meminta izin (dari atasan Anda) untuk mengkompilasi kode sumber gitsebelum melakukannya. Dia akan memberi tahu Anda, atau Anda akan berdiskusi dengannya, tentang perincian praktis (jika ia menerima solusi semacam itu) mengenai mentransfer kode sumber itu dari luar ke komputer kerja Anda.

Hal pertama yang akan saya lakukan adalah mengidentifikasi secara spesifik apa yang ditentang oleh badan pemerintah (mungkin departemen TI). Jika mereka memiliki ruang penyimpanan, tetapi tidak ada cara hosting VM untuk server, maka masalahnya mungkin departemen TI mengatakan tidak untuk server SVN atau GIT dan itu adalah perbedaan besar. Jika masalahnya adalah negara asal - yaitu kita tidak mempercayai alat yang dibuat oleh entitas asing - itu adalah masalah yang berbeda.

Anda dapat menjalankan GIT sepenuhnya dalam sistem file, yang telah saya lakukan pada proyek-proyek kecil sebelum saya siap untuk melakukan apa pun dengan mereka. GIT juga tidak memerlukan hak administratif untuk menginstal.

Jika Anda benar-benar tidak dapat menggunakan Git untuk alasan apa pun, maka Anda memiliki beberapa opsi yang tersedia untuk Anda:

• Didik: Dengan tidak mengizinkan kontrol versi, mereka memperkenalkan risiko yang signifikan. Anda perlu kemampuan untuk mundur dari perubahan yang terbukti lebih bermasalah. Anda memerlukan kemampuan untuk menghemat uang dan waktu pemerintah, dan SCM melakukannya. Anda harus bisa menjelaskan caranya dengan jelas. Anda juga mungkin perlu melakukan analisis alternatif untuk benar-benar mengarahkan pulang intinya.
  • Satu alternatif akan menjadi tuan rumah Git
  • Git filesystem lain
  • Pilih setidaknya satu, tetapi tidak lebih dari dua alat SCM alternatif
  • dan akhirnya apa rasanya bekerja tanpa kontrol versi
• Perkembangan era 70-an: Ada alasan patchdan diffdibuat sejak dulu (tahun 80-an). Mereka adalah teknologi yang memungkinkan kontrol versi dimungkinkan.

Seperti apa perkembangan era 70-an? Ini tidak cantik, tapi beginilah cara kami memulai. Aplikasi jauh lebih kecil. Pada dasarnya mereka memiliki beberapa hal umum:

• Ada konsep standar emas . Ini adalah kode sumber utama yang memiliki fitur lengkap.
• Ada tim Manajemen Konfigurasi (CM). Tanggung jawab mereka adalah mendapatkan perubahan dari pengembangan menjadi standar emas dengan benar. Di sinilah Anda membutuhkan patchdan diffuntuk menggantikan tim.
• Anda bekerja dari salinan lokal kode sumber. Anda menyelesaikan fitur secara keseluruhan dan mengirimkannya ke tim CM untuk diintegrasikan. Biasanya ada dokumen yang menyertainya sehingga file baru dibuat dan file usang dihapus, dll.
• Kemudian Anda memperbaiki kesalahan apa pun dari proses integrasi.
• Sebelum Anda dapat menikmati fitur atau perbaikan bug lain, Anda mendapatkan salinan baru dari standar emas.

Pada dasarnya, ini adalah proses yang rawan kesalahan dengan banyak potensi kesalahan terjadi. Gagasan "percabangan" mudah diterapkan, tetapi mimpi buruk untuk dikelola. Masalah utamanya adalah ketika Anda memiliki terlalu banyak salinan kode sumber, sulit untuk memahami apa yang menjadi dasar produksi yang tepat. Demi kepraktisan, Anda harus menjadi utas tunggal.

Inilah yang perlu Anda sertakan dalam analisis alternatif.

Mengingat kendala yang Anda sebutkan di komentar (misalnya: tidak bisa sampai ke halaman unduhan Git, platform Windows, dan menggunakan Visual Studio 2005), saya dapat melihat 2 opsi, yang keduanya telah saya gunakan sebelumnya dalam situasi yang sama:

1. Gunakan Visual SourceSafe seperti yang disarankan Emerson dalam komentar. Saya bekerja dengan tim menggunakan VS 2005 beberapa tahun yang lalu, sementara sebagian besar perusahaan menggunakan kontrol versi standar di Linux / Unix, dan mereka dengan senang hati menggunakan Visual SourceSafe untuk CM mereka. Ini cukup kuno pada saat ini, tetapi lebih baik daripada tidak sama sekali.
2. Berbicara tentang lebih baik daripada tidak sama sekali, saya sendiri berada dalam ikatan yang sama. Jika Anda bahkan tidak dapat menggunakan VSS (mungkin plugin tidak diinstal?), Dan karena Anda mengatakan ada banyak ruang penyimpanan yang tersedia, mudah-mudahan Anda diizinkan untuk menggunakannya. Saya menerapkan protokol kontrol versi berbasis file manual. Di akhir setiap hari kerja, saya akan menyalin basis kode saya ke direktori yang diberi cap tanggal. Jika saya perlu merujuk kembali ke pekerjaan sebelumnya (atau memutar kembali), saya akan melihat direktori tanggal sebelumnya untuk menemukan perubahan yang saya butuhkan. Karena Anda memiliki Visual Studio tersedia, dalam beberapa jam, Anda mungkin dapat menggunakan VS 2005 untuk menulis alat sederhana untuk membantu Anda mengotomatisasi pembuatan direktori dan menyalin file.

Mereka memiliki banyak ruang penyimpanan

Apakah Anda diizinkan menggunakannya atas keputusan Anda?

Jika demikian, Anda dapat membuat repositori sistem file jarak jauh yang lebih baik daripada tidak sama sekali. Kelemahannya adalah mendorong menjadi lambat saat proyek berkembang karena gitperlu mengunduh seluruh repositori untuk mencari perubahan ...

sejauh ini komputer berperilaku seperti pengguna biasa, melarang saya untuk menginstal perangkat lunak pihak ketiga.

gitjuga hadir sebagai aplikasi portabel sehingga Anda dapat menginstalnya di jalur $ HOME atau% USERPROFILE% Anda.

Sebagai kesimpulan: Saya tidak akan membiarkan mereka melarang saya menggunakan SCM ¹ . Saya akan menggunakannya "secara pribadi". Lagi pula tidak ada yang tidak tahu apakah kode Anda telah dikembangkan dengan atau tanpa diperiksa di suatu tempat ...

¹ ) ketika saya mulai menggunakan gitbeberapa tahun yang lalu pelanggan saya lebih suka SCM berbeda yang cukup lambat dan tidak dapat diandalkan (yang merupakan semacam NOGO untuk SCM setelah semua (o;). Saya menggunakan git"secara pribadi" di atas SCM lainnya dengan remote "berbasis file" pada jaringan berbagi dan hanya memeriksa ke dalam SCM mereka setelah versi baru produk telah dirilis.

Lingkungan Anda

Pertama-tama, saya tidak akan begitu pesimis seperti ditunjukkan dalam banyak komentar dan jawaban. Ya, ini adalah "zaman batu", tetapi ada keadaan yang jauh lebih buruk. Jika lingkungan kerja Anda secara keseluruhan (kolega, lokasi, pembayaran, pekerjaan pemrograman yang menarik, dll.) Baik dan sesuai selera Anda, maka tentu saja tetaplah dengan itu. Mengenai IT, itu adalah apa adanya. Ini tidak hanya terjadi di lembaga pemerintah, tetapi juga di perbankan, asuransi atau di mana pun ada fokus yang sangat besar pada keamanan, atau struktur yang sangat lama.

Memasukkan stik USB dan menjalankan beberapa .exe dari sana akan segera menyebabkan penghentian di tempat lain, jadi saya tidak akan menyarankan Anda mencoba untuk menghindari apa pun.

Coba git sekali lagi

Sekarang pada pilihan Anda. Saya akan sangat menyarankan git, bukan svn untuk Anda. Jika Anda melakukan proyek satu orang, maka git hanyalah direktori lokal .gitdi dalam root aplikasi Anda, tidak ada yang lain.

Jangan meminta "SCM" kepada bos / IT Anda, tetapi mintalah mereka secara khusus untuk memasang gitpada mesin Anda sehingga Anda dapat berkembang lebih cepat dan dengan kualitas yang lebih tinggi. Jelaskan kepada mereka bahwa Anda tidak ingin mendorong kode Anda ke tempat lain, bahwa Anda tidak memerlukan server yang berjalan di suatu tempat, dan itu tidak akan menghabiskan banyak ruang atau waktu pemeliharaan.

Git akan meningkatkan kecepatan dan kualitas untuk Anda hanya karena Anda dapat bekerja dengan lebih percaya diri (karena Anda dapat membatalkan setiap perubahan yang Anda lakukan) dan memungkinkan Anda untuk bekerja pada banyak cabang pada saat yang bersamaan. Yaitu, jika Anda mengerjakan tugas besar, dan ada sesuatu yang perlu Anda perhatikan segera, Anda bisa langsung beralih ke cabang baru, cepat memperbaikinya, dan kemudian kembali ke tugas yang sudah berjalan lama.

Melakukannya secara manual

Jika tidak mungkin sama sekali, maka tentu saja Anda dapat melakukan kontrol sumber manual. Buat "tag" manual dengan menyalin kode Anda sendiri (mungkin membuat direktori baru dengan tanggal / waktu, dan deskripsi singkat tentang apa yang berubah). Simpan Changelog dengan daftar tidak hanya dari perubahan Anda, tetapi juga file yang Anda ubah, dan bahkan mungkin lebih detail.

Buat "cabang" dengan, sekali lagi, menyalin pekerjaan Anda, dan ketika tiba saatnya untuk bergabung kembali, berkreasilah menggunakan beberapa alat "diff" atau "diff3" yang sewenang-wenang - Saya tidak tahu apakah Anda memiliki yang tersedia, Anda harus Temukan.

Jika semua ini menghabiskan banyak waktu, maka perhatikan baik-baik apakah benar-benar layak bagi Anda untuk meniru SCM. Jika Anda menemukan bahwa itu adalah layak, kemudian berbicara dengan atasan Anda lagi. Tunjukkan padanya manfaat SCM manual Anda (bukan hanya "Saya memiliki salinan semua pekerjaan lama saya" tetapi "ketika bug XYZ terjadi, saya segera dapat menemukan alasannya, 5 rilis yang lalu"). Kemudian beri tahu mereka seberapa cepat ini dengan git.

Jelas, jika ini membuat Anda gila, mencari pekerjaan selalu merupakan pilihan.

Saya pikir banyak orang di sini kehilangan "institusi pemerintah" dari pertanyaan ini. Beberapa jaringan pemerintah memiliki peraturan yang sangat ketat tentang peranti lunak yang diizinkan, dan melanggar aturan itu merupakan pelanggaran yang bisa dipadamkan, bahkan mungkin kriminal. Saya akan mendorongnya melalui manajemen untuk melihat apakah Anda bisa mendapatkan gerakan yang disetujui untuk menginstal perangkat lunak. Saya tidak akan pergi koboi dan menginstal barang sendiri. Jika Anda menjalankan Linux / UNIX, lihat apakah RCS (perintah ci / co) atau SCCS (perintah sccs) diinstal. Ini adalah alat SCM lama yang dulunya cukup standar. Ini tidak cantik tapi lebih baik dari apa yang akan saya tulis di bawah ini. :)

Karena Anda memiliki "banyak" ruang disk, buat bagan sumber. Apa dasar-dasar SCM dalam skala kecil? Mampu memeriksa perubahan, melihat apa yang berubah, menandai barang, dan kembali ke versi lama jika perlu. Satu tingkat di atas sumber-pohon, buat Makefile atau skrip, tergantung pada apa yang Anda miliki, yang melakukan hal berikut (ini adalah rasa Linux / UNIX, perintah Windows akan berbeda)

make checkin - cp -sumber-tree source-tree-date (setidaknya satu menit, jika bukan yang kedua, seperti source-tree-20171205115433)

make status - diff -R source-tree source-tree-date | kurang (akan ada sedikit logika di sini, default ke cadangan terbaru atau memberikan argumen berbeda terhadap suatu versi

make tag - ln -s source-tree-date release1.0 (buat tautan ke versi tertentu)

make revert - rm -r source-tree && cp -a source-tree-date source-tree

Jual ke mereka

Anda meninggalkan komentar ini :

Mereka memiliki drive jaringan yang saya tidak tahu caranya tetapi itu membuat cadangan dalam periode. Iya. Saya menggunakannya dan saya menyimpan aplikasi saya di sana.

Pergi ke atasan Anda dan katakan sesuatu dalam nada ini:

Bos, saya perhatikan kami memiliki sistem tempat kami meletakkan aplikasi di drive jaringan dan beberapa jenis layanan membuat cadangan dan melacak sejarah. Sepertinya saya hanya menerapkan sistem kontrol sumber kami sendiri dengan melakukan ini. Kami mungkin dapat membebaskan banyak ruang dan membuat keseluruhan sistem menjadi lebih sederhana dengan beralih ke sistem manajemen sumber kontrol khusus, seperti SVN atau git. Kami akan mendapat banyak manfaat: pencadangan versi historis yang lebih sederhana, alat untuk memahami perubahan apa yang dilakukan pada file dari waktu ke waktu (info yang sangat berguna untuk debugging), cara yang lebih mudah untuk membatalkan kesalahan, dan cara yang lebih mudah untuk menggabungkan perubahan orang yang berbeda.

Saya telah menggunakan sistem semacam ini sebelumnya, dan mereka sangat bagus dalam tugas yang dilakukan oleh pengaturan kustom kami. Jauh lebih sulit untuk membuat kesalahan dengan mereka daripada sistem kita saat ini. Mereka juga teknologi yang sangat matang dan banyak digunakan; alat-alat ini telah banyak digunakan selama lebih dari 20 tahun. Dan di atas itu, kita dapat menggunakan perangkat lunak paling populer tanpa membayar sepeser pun dalam perizinan.

Saya dengan senang hati membantu memilih klien dan server dan mengaturnya. Saya berharap hanya akan memakan waktu [insert estimate here]berjam - jam untuk menginstalnya jika saya bisa mendapatkan mesin. Mesin apa pun akan melakukannya, bahkan desktop lama akan dihentikan, selama kita dapat mengaksesnya melalui jaringan.

Ringkasan tingkat tinggi di sini adalah bahwa Anda perlu memasukkannya ke dalam istilah yang dapat mereka pahami dan cenderung berpikir layak:

• Membebaskan sumber daya (perangkat keras dan orang) untuk keperluan lain
• Risiko lebih rendah (kesalahan manusia, teknologi stabil)
• Peningkatan produktivitas
• Biaya kecil untuk diimplementasikan

Atasan Anda bukan orang teknis dan mereka tidak peduli dengan masalah teknis. Tetapi jika Anda dapat membingkai masalah dalam hal uang dan hal-hal yang membutuhkan uang, telinga mereka mungkin sedikit lebih baik.

Nah, setelah membaca pertanyaan Anda dan banyak komentar, saya mengerti bahwa Anda memiliki kendala / skenario berikut:

• 1 orang per proyek;
• Anda tidak bisa menggunakan alat eksternal selain Visual Studio 2005 untuk proyek Anda; Anda tidak dapat menggunakan GIT atau SCM lainnya;
• saat bekerja secara lokal, Anda tidak dapat membiarkan proyek dalam keadaan rusak, karena Anda memiliki cadangan otomatis dari waktu ke waktu, dan Anda harus membuatnya berfungsi sepanjang waktu;
• Anda perlu beberapa riwayat untuk melacak perubahan;

Jika Anda tidak dapat menggunakan Visual Source Safe (yang memiliki plugin untuk bekerja dengan VS 2005), maka Anda dapat menggunakan pendekatan lain.

Berdasarkan item di atas, saya sarankan Anda mengatur folder proyek Anda seperti di bawah ini:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Aturan dasar untuk diikuti di sini:

• kontrol kode Anda akan dilakukan dalam folder proyek;
• Anda tidak pernah bekerja di "trunk";
• Anda bekerja di "temp" , mengimplementasikan pengujian unit , memanggil build.bat , dan kemudian save_on_trunk.bat ;
• PENTING: laksanakan pengujian unit yang berjalan dalam isolasi total; Anda memerlukan ini untuk menjamin bahwa kode baru tidak akan merusak bagasi;
• karena Anda memiliki cadangan otomatis, kemungkinan kehilangan kode akan lebih kecil; oleh karena itu, Anda hanya perlu membuat kode "trunk" agar selalu dalam kondisi aktif.

Anda kehabisan solusi teknis. Hanya solusi politik yang tersisa.

1) Unionisasi pengembang. Jika sudah ada serikat pekerja, tantang posisi mereka karena tidak cukup mewakili kelas karyawan yang merupakan pengembang. Jika membentuk persatuan pengembang gagal mendapatkan dukungan dari setengah pengembang, GO. Anda tidak cocok.

2) Iklan koran. Jika pemerintah Anda tidak menjamin kebebasan berbicara sebagai masalah hukum yang diakui, ini akan membuat Anda dipecat.

Git untuk Windows memiliki versi "portabel" . Anda dapat menyalin ini ke PC Anda, atau menyimpannya di memory stick, tanpa harus menginstal apa pun. Jika masalahnya hanya instalasi, ini akan menjadi solusi.

Perhatikan bahwa jika mereka menentang SCM, Anda mungkin ingin mengajukan pertanyaan tajam tentang ISO-9001, DO-178B atau standar pengembangan perangkat lunak lain yang relevan.

Jalankan saja git di atas direktori kosong, tanpa server yang terlibat sama sekali. Sama sekali tidak masalah bahwa tidak ada orang lain yang menggunakan kontrol versi, karena Anda dapat mengontrol versi direktori Anda. Git dirancang untuk persis skenario pengantar SCM ini, dan itu bekerja dengan baik.

Anda akan menjadi pahlawan ketika orang kedua mulai menggunakannya, bahkan jika Anda harus menunggu beberapa dinosaurus menendang ember untuk itu menyebar. Itu tidak kompeten untuk mengelola basis kode besar tanpa SCM sekarang. Ini seperti menjalankan bisnis tanpa mengaudit apa pun, sebenarnya.

Sebenarnya ada tiga hal terpisah yang ingin Anda tekankan sebagai pengembang profesional: Ulasan kode, riwayat versi, dan melacak permintaan perubahan.

Anda sendiri dapat melacak permintaan perubahan. Tidak sebagus dengan alat yang tepat, tetapi Anda bisa. Bagian kedua adalah ulasan kode. Untuk itu, Anda memerlukan salinan kode Anda sebelumnya, dan alat diff. Ketika Anda berpikir suatu perubahan siap, Anda memeriksanya sendiri dengan membandingkan dengan hati-hati dengan versi sebelumnya, lalu ganti versi sebelumnya dengan yang baru.

Untuk kontrol versi, jika tempat kerja Anda tidak memungkinkan solusi yang layak, itu adalah kotak DVD yang dapat ditulis yang Anda butuhkan. Setiap kali Anda memiliki versi yang ingin Anda simpan kembali, Anda membuat DVD baru.

(Jelas semua ini bukan saran yang harus diambil kecuali Anda berada di tempat kerja yang benar-benar buruk seperti OP tampaknya).