Kami mulai dengan satu pengembang, dan satu repo svn yang berisi semua kode kami:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(pada saat itu ini merupakan peningkatan besar). Setelah ini mendapat kesempatan untuk tumbuh sedikit, kami mulai mengalami masalah dengan dependensi melingkar, testuites lambat, dan kesulitan umum menggunakan kembali kode (karena misalnya set fitur situs web1 telah merangkak ke dalam modul generik-a).
Ingin memodulasi basis kode, dan berharap kita segera pindah ke git (dan setelah membaca di suatu tempat bahwa git tidak suka svn mega-repos), kami telah beralih ke struktur yang jauh lebih terperinci:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
Secara konsep ini hebat. Lebih banyak kode modular, test suite lebih cepat, lebih mudah untuk didokumentasikan, dll. Kami membuka beberapa komponen generik kami, dan membuat semua modul dapat diinstal (gunakan pip install -e .
untuk menginstalnya di development
virtualenv).
Kami membuat ^/srv/trunk
repositori yang berisi struktur folder dari lingkungan runtime, yaitu. ^/srv/trunk/lib
untuk modul, /srv/trunk/src
untuk sisa-sisa ^/foo/trunk
, ^/srv/trunk/www
untuk website dll
Dan akhirnya (mengambil ide dari perforce, yang sudah lama saya kerjakan [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) kami membuat "vcs- ambil "file teks yang mencantumkan semua repo yang relevan dan di mana mereka harus diperiksa ke lingkungan dev, dan perintah yang sesuai untuk melakukannya. Misalnya garis vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
akan menyebabkan salah satu (pertama kali)
cd /srv/lib && svn co ^/module-a/trunk module-a
atau (sesudahnya)
cd /srv/lib/module-a && svn up
dan juga untuk repositori github (baik paket vendor kami sendiri maupun yang diubah / tidak diubah).
Kami telah menggunakan proses vcs-fetch yang sama untuk menciptakan lingkungan produksi, tetapi kami dengan cepat mengetahui bahwa kami tidak memiliki cara untuk mengetahui versi mana yang digunakan untuk berjalan dalam prod setelah melakukan vcs-fetch.
Dengan mega-repo, kita bisa mencatat nomor revisi sebelum memperbarui prod dari trunk, dan kembali adalah sangat mudah svn -r nnn up .
. Dengan kode di svn dan git (dan satu modul dalam hg) - dan ~ 120 repo, tidak jelas bagaimana melakukan ini ..
Saya membaca http://12factor.net/ hari ini, dan faktor pertama adalah "Satu basis kode" jadi saya juga bertanya-tanya apakah saya jauh dari jalan yang benar di sini?
Satu ide yang saya miliki adalah membuat skrip deploy yang akan membuat pip-installable "deployment" -wheels dan "bundle" bersama-sama dalam sebuah requirements.txt
file. Penempatan kemudian akan melibatkan pembuatan virtualenv baru, pip-instal file requirement.txt daftar roda penyebaran, dan beralih virtualenv aktif. Mengembalikan ke sebelumnya hanya akan melibatkan pengalihan virtualenv kembali (tetapi kecuali kami ingin menyimpan virtualenv selamanya, itu tidak akan memungkinkan kami untuk kembali ke titik waktu - dalam pengalaman saya yang belum pernah dibutuhkan sekalipun).
Pada titik ini saya bertanya-tanya apakah saya berjalan ke arah yang salah, atau apakah saya belum berjalan cukup jauh di jalan yang benar ..? (semua yang saya baca terus berbicara tentang "aplikasi Anda", dan saya tidak tahu bagaimana itu berarti menjalankan 14 situs web dari basis kode yang sama ...)