Pertanyaan Apa sajakah tips untuk membuat kompilasi proyek saya di checkout baru setiap saat?


Lebih sering daripada yang saya ingin akui aku sudah punya orang baru untuk proyek melakukan checkout hanya untuk menemukan mereka kehilangan berbagai sumber daya, dll, pengaturan. Saya ingin memiliki kebiasaan yang tepat untuk membuat kompilasi proyek saya menjadi lancar seperti yang dapat dilakukan dari checkout baru.

Apa sajakah tips atau saran tentang cara menyusun proyek saya sehingga mereka tidak memiliki masalah kompilasi pada pemeriksaan baru dari kontrol versi?

Saya sudah mulai menyimpan folder "Resources" di proyek-proyek saya yang berisi semua referensi dll yang diperlukan dalam kontrol sumber. Adakah yang bisa membuat beberapa saran?


5
2018-01-13 00:55


asal


Jawaban:


Dengan asumsi Anda berada di lingkungan Visual Studio, berikut adalah beberapa hal yang mungkin Anda anggap berguna, YMMV tentu saja dan perhatikan bahwa kami menggunakan Subversion, tetapi alat VCS apa pun yang harus dilakukan ...

  • Tempatkan semua (atau sebanyak mungkin) dependensi di bawah kontrol versi dan rujukan ini dalam proyek Anda. Kami menggunakan Eksternal Subversion untuk mengelola ini.
  • Jangan versi kontrol direktori keluaran standar (bin, obj), yaitu gunakan svn: ignore
  • Demikian juga, abaikan item pengguna kontrol versi (* .user, * .suo)
  • Juga jangan file konfigurasi kontrol versi (App | Web.config), sebagai gantinya, buat App.default.config dan dalam proyek Anda, tugas BeforeBuild salin file ini ke App.config. Hal ini memungkinkan Anda untuk menjadi mewah dengan menggunakan RegEx dan token untuk menyusun kompilasi per pengembang atau membangun server, itu juga memungkinkan Anda untuk menghapus file App.config yang ada di CI membangun untuk memastikan bangunan murni setiap waktu. Ini juga memungkinkan pengembang untuk mengacak-acak konfigurasi tanpa harus mengganggu orang lain sampai mereka siap, yaitu memperbarui App.default.config.
  • Kontrol semua versi lainnya :)
  • Jika Anda perlu mengontrol versi binari (MSI, output DLL, dll) sebagai hasil kompilasi Anda, dalam proyek target AfterBuild Anda (wixproj, dll) salin hasilnya ke direktori lain yang berada di bawah kontrol versi. Salah satu tip menggunakan Subversion adalah Anda dapat menambahkan / berkomitmen ke direktori svn: externals, yang memungkinkan Anda untuk mendorong pustaka, dll untuk proyek yang mereferensikannya.

Kiat akhir - Setelah Anda melakukan checkout yang bersih dan memiliki kompilasi yang berhasil, periksa untuk melihat apakah ada modifikasi dalam copy pekerjaan Anda, mis. TortoiseSVN -> Periksa modifikasi. Jika Anda mendeteksi perubahan, maka file-file ini mungkin perlu diabaikan.


2
2018-01-13 03:38



Temukan komputer lama yang tidak digunakan dan atur untuk "rolling build" otomatis:

  1. Tunggu sampai seseorang memeriksa perubahan
  2. Perbarui ke versi terbaru semua file.
  3. Bersihkan semua file kontrol non-sumber (make clean tidak cukup - pindai puing-puing dan lepaskan)
  4. Membangun.
  5. Jalankan tes unit.
  6. Sekali sehari, simpan binari dari run yang sukses. Sebut saja "build resmi" untuk hari itu.

Jika build atau tes gagal, kirim email dengan kesalahan. Sertakan daftar perubahan yang diambil di # 2.

Jika Anda benar-benar tidak dapat menemukan mesin, lakukanlah dalam mesin virtual.


2
2018-01-13 03:26



Alat seperti nmaven dapat membantu dengan masalah ketergantungan, (Meskipun Anda mungkin harus melihat ke maven java dokumen untuk info ....)

Alat integrasi berkelanjutan seperti cruisecontrol berulang kali check-out dan membangun aplikasi Anda setelah setiap checkin, yang dapat mengingatkan Anda untuk checkins yang memecah build ... Juga, mereka dapat menjalankan tes unit Anda, dan dengan demikian memperingatkan Anda untuk setiap regresi yang disebabkan oleh checkin Anda, juga .. .


1
2018-01-13 01:06



Adakah yang bisa membuat beberapa saran?

  1. Simpan file, yang perlu Anda bangun, di satu tempat (satu direktori dan subdirektorinya) ... kebanyakan sistem kontrol versi menyebut ini sebagai "direktori kerja" Anda
  2. Perangkat lunak kontrol versi Anda memiliki perintah untuk membuat daftar perbedaan antara apa yang ada di direktori kerja Anda dan apa yang ada di bawah kendali versi ... "perbedaan" ini mencakup file yang ada di direktori kerja dan yang tidak berada di bawah kontrol versi
  3. Setel perangkat lunak kontrol versi Anda untuk mengecualikan (dari daftar yang ditampilkan oleh langkah 2.) file yang jenisnya tidak ingin Anda simpan ... misalnya, Anda mungkin ingin menyimpan hanya kode sumber, dan mengecualikan *.obj dan seterusnya ... tidak termasuk jenis file ini berarti ketika Anda menjalankan langkah 2, daftar perbedaan tidak penuh dengan file yang tidak ingin Anda simpan
  4. Pertimbangkan memiliki mesin build, yang secara otomatis melakukan check-out-and-builds (dan yang mengirim email kepada Anda jika 'build rusak')

1
2018-01-13 03:10



Debian Linux memiliki alat yang sangat hebat yang disebut pbuilder, yang menciptakan citra sistem yang baru dipasang dan kemudian mencoba untuk membangun kode Anda. Ia hanya bekerja dengan sistem paket Debian, tetapi Anda bisa mencuri ide-ide, yang benar-benar bagus.

Mengotomatisasikan bangunan Anda dari lingkungan chroot atau mesin virtual yang tampak seperti instalasi baru. Script build Anda kemudian akan menginstal DLL dan sebagainya. Atau skrip konfigurasi Anda akan menyebutkan dependensi yang hilang (semuanya, bukan hanya yang pertama).

Ini jam 1 pagi dan saya kedengarannya membingungkan, tetapi dua ide penting:

  • Memiliki mesin virtual atau direktori chroot yang dapat meniru sistem kosong. Hari-hari ini mesin virtual mungkin paling mudah.

  • Tweak sistem build Anda sampai secara otomatis memeriksa dan membangun di mesin virtual Anda --- atau yang lain mengeluh tentang apa yang hilang.

Pada titik itu Anda dapat membuat proses menjadi bagian dari bangun malam otomatis, dan Anda akan menjadi kemping bahagia :-)


1
2018-01-13 06:06



Setiap sumber daya / DLL / pengaturan harus diperiksa ke dalam kontrol versi bersama dengan kode sumber.

Mereka harus diberi label dan diperlakukan sama dengan kode sumber, yang akan memungkinkan Anda untuk menghubungkan sumber daya ini dengan sumber dan memperlakukan kode sumber / sumber daya / pengaturan sebagai satu kesatuan.

Di perusahaan saya, kami menggunakan Rational ClearCase. Segala sesuatu dicentang ke kontrol sumber, dengan pengecualian file kode sumber yang dihasilkan (misalnya file .cpp dan .h yang dihasilkan dari compiler MIDL). Karena ini, kebanyakan build berjalan dengan cukup lancar.

Anda juga perlu memastikan bahwa dependensi Anda diatur dengan benar, sehingga ketika file sumber diubah, semua pustaka yang bergantung akan dibangun kembali.


0
2018-01-13 01:07



Anda dapat membuat daftar periksa komprehensif yang Anda konsultasikan sebelum setiap check-in - tetapi itu akan memakan waktu dan kesalahan rawan (terutama di beberapa pengembang, tidak semua orang memiliki ciri-ciri kepribadian untuk mengikuti daftar periksa secara ketat setiap kali).

Sebagai gantinya, buat server Integrasi Kontinyu sederhana - CruiseControl.Net adalah sumber terbuka; TeamCity oleh JetBrains gratis - yang memeriksa build bekerja setiap kali checkin dilakukan.

Dengan cara ini, Anda tahu pasti - daripada menyimpulkan hal-hal bekerja karena daftar itu diikuti.


0
2018-01-13 03:17



SCons adalah alat lain yang bekerja lintas platform dan membantu mengelola dependensi Anda. Mirip dengan gnu membuat Anda memiliki "file scons / skrip" - dan fakta bahwa itu menggunakan python memberi Anda banyak fleksibilitas.

http://www.scons.org/

(Saya tidak ada hubungannya w / SCons; kami hanya menggunakannya)


0
2018-01-13 03:22