Geçmiş projelerin çalışma geliştirme ortamlarında etkili bir şekilde tutulmaları?


19

Geçmiş bir projeyi yürütmek istediğimde, onu bulabilmemin ve çalışabilmesi için her şeyi yeniden ayarlamamın uzun zaman alacağını görüyorum.

Örneğin, Linux'ta oluşturduğum python projelerim var ve Linux'a kolayca yüklenen yazılım paketlerine bağlı, ancak artık kullandığım Linux VM'ye sahip değilim. Ve diğer projelerimden bazıları web sunucusu yapılandırması, PATH değişkenleri, sdk, IDE, OS sürümü, cihaz vb. Gibi diğer değişkenlere bağlı.

Birisi bu sorunu ele almak için etkili bir yol var mı? Şu an itibariyle kendimi sadece kaynak kodun yedeklenmesi konusunda endişeliyim, ancak çalışma geliştirme ortamını yeniden kurmak zor ve çalışma geliştirme ortamını da korumak zordur .


6
NSA benim
yedeğim

Yanıtlar:


17

Geçmişte yaptığım şey, fiziksel geliştirme makinesini bir VM'ye dönüştürmek ya da zaten bir VM ise, gelecekteki kullanım için saklamak. Disk alanı kullanımı için istediğim kadar verimli değil, ancak alan ucuz. Ayrıca, bu süreç ihtiyaç duyulduğunda gelecekte bir ortamı yeniden yapılandırmaya çalışmaktan çok daha ucuzdur.


2
Ayrıca, tüm yazılımların / sürümlerin kopyalarını saklamanız ve projenizi bir komut dosyasından yüklemeniz gerektiğini düşünüyorum. Kurulumu her seferinde hızlı bir şekilde yeniden üretmek için ileriye doğru büyük bir adım .
tzerb

Bu geçmişte yaptığım şeydi ... farklı istemci ortamlarını vb. Desteklemek için harikaydı. Eğer bir temel VM kullanıyorsanız, her ardışık VM sadece bir diff dosyası olabilir, sorun ... Ama ben şahsen sabit disklerin ucuz olduğunu düşünüyorum. :-)
davewasthere

LXC desteğinin iyileşmesi ile linux ortamlarıyla uğraşırken VM yerine kullanmak güvenlidir. Kaynaklara çok daha az talep ediyor ve çok daha hızlı. ATM onları yönetmek için en iyi araçtır liman işçisi
karka91

11

Şu anda en sevdiğim yöntem, bir proje için TÜM gerekli bağımlılıkları yükleyen, kaynağı indiren ve her şeyi bağlayan bir komut dosyası sağlamaktır. Bazı komut dosyalarının iki modu vardır - biri üretim için, bu genellikle diğer modun bir alt kümesidir: geliştirme.

Bazı ortamların bir komut dosyası ile yüklenmesi yalnızca 5 dakika sürer - bu durumda, yerel bir VM'yi sabah işe geldiğimde proje komut dosyasını dağıttığım hedef işletim sisteminin yeni bir yüklemesiyle tutarım - ve sonra tüm kodlamayı yaparım ilgili VM örneğindeki ilgili çalışma. Ayrılmadan önce tüm değişiklikleri git üzerinden fiziksel makineme veya merkezi veri havuzuma aktarıyorum ve VM'yi sonlandırıyorum.

Ortamın kurulumu daha uzun sürerse (uzun süren yüklemeler, indirmek için büyük dosyalar, bunun gibi bir şey) Yukarıdaki prosedürü haftada bir kez yaparım.

Avantajı, yeni bir makineye ve / veya üretim sunucusuna konuşlandırılmasının çok kolay olması, tümünün komut dosyasında belgelenmesi ve komut dosyasının çok sık doğrulanmasıdır.


4

Tanımladığınız kavram, yapılandırma yönetimidir. Bu, göründüğü gibi, bir ortamı tanımlamanın, kaydetmenin, versiyonun / parçanın ve raporlamanın bir yoludur. Genellikle sürüm kontrolü ve oluşturma yönetimi ile güçlü bir şekilde ilişkili bir görevdir, ancak aynı kavramlardan ve aynı işleme ve depolama mekanizmalarından bazılarını kullansa bile, genellikle ayrı bir strateji gerektiren yeterince belirgindir.

Yapılandırma yönetimi, bir çalışma ortamını kontrol altında tutmaya yardımcı olmanın yanı sıra, yazılımın kullanıldığı farklı çalışma ortamlarının bir kaydını oluşturmaya da yardımcı olur (belirtildiği gibi geliştirme, test / KG, rutin müşterilere dağıtım, özel dikkat veya özel yapılandırma gerektiren müşterilere dağıtım veya yapı özellikleri vb.).

Söylediğim gibi, bu genellikle kaynak sürüm kontrolü ile çakışan bir görevdir ve genellikle yapılandırma yönetimi verileri hem dokümantasyonda hem de kaynak deposunda kaynağın yanında bulunur. Olması gerekmiyor, ancak çoğu zaman bir kolaylık meselesi.

Yapılandırma yönetiminin bazı yönlerinin otomasyonu son yıllarda büyük ölçüde iyileşmiştir. Bazı yanıtlar ve yorumlar komut dosyalarını yapılandırma yönetimini teşvik etmenin bir yolu olarak önerdi ve komut dosyaları tekrarlanabilir sonuçlar elde etmeye yardımcı olmak için iyi bir yanıttır, ancak çoğu zaman elle hazırlanmış komut dosyaları kendi başlarına tutarsız ve eksiktir. Bunun gelişmesinin bir yolu da otomatik provizyon yöntemidir. Kukla veya şef gibi sistemlerbelirli bir kullanıcı veya makine veya belirli bir görev profili için yazılım bileşenlerini ve sistemlerini belirlemeye yardımcı olun ve eksiksiz bir makine veya ortam oluşturmak için elden uzak bir yaklaşıma izin veren 'tarifler' sağlayın. Temel olarak bir yazılım dağıtım deposu kavramını alır ve yalnızca bir sistem için gerekli olan yazılım paketlerini değil, aynı zamanda her pakete özel yapılandırma profillerini sağlayarak kullanıma uygun şekilde kullanılmasını sağlayarak genişletir ve genelleştirir. durum.

Vagrant bunu biraz farklı bir yöne götürür ve sanal makinelerin tanımlarını hızlı bir şekilde döndürmenin bir yolunu sunar, böylece bir VM'nin sanal yazılımı ve donanımı otomatik olarak sağlanır ve bir donanımın belirli bir temsilini yeniden üretmek için uygun bir yol olabilir. yazılımınızın kullanıcısı tarafından kullanılan ortam.

Her sistemin (ve varyasyonların) kurulumu biraz zaman alır, ancak yeniden yükleme ve ortak bir görev olarak yeniden yapılandırma görevini bulursanız net bir değere sahiptir.


Lütfen ifadenizde bahsettiğiniz stratejiyi genişletebilir misiniz? "Ancak genellikle ayrı bir strateji gerektiren yeterince farklıdır?" Vagrant kullanacak ve kaynak kodumun deposunda bir VM yapılandırması depolayacaktım ve hangi noktada farklı muamele görmesi gerektiğini merak ediyordum?
CL22

3

Docker iyi bir seçenek olurdu. İstediğiniz sanal makine için bildirim olarak çalışmak üzere bir dockerfile kullanabilirsiniz. Herhangi bir görüntü saklamanız gerekmez, gerekli olanı indirecektir. Ayrıca, kendi görüntülerinizi kullanabilir, böylece kendi temel görüntünüzü oluşturabilir ve ardından ortamın gerektirdiği bileşenleri ekleyebilirsiniz.

Bağlantı birimini kullanarak bu, iş akışınızın diğer bölümlerini de geliştirebilir:

  • Oluşturulan ortam, projenizle aynı CVS'ye yerleştirilebilir, bu da size sürümlü bir ortam sağlar (temiz!)
  • Liman işçisi, projelerinizi üretimde başlatmanın baş ağrılarını azaltarak canlı ortamı sağlamak için kullanılabilir.
  • Diğerleri sizinle çalışmaya başlarsa, bu büyük ortam kurulumunu yüklemek için dockerfile yeterlidir.

Bu yüzden burada VM kullanma hakkındaki fikirler sadece kısmen doğru, HDD'lerin gittikçe büyüdüğünü biliyorum, ancak sahip olduğunuz tüm alanı kullanmak için bir neden değil. Ayrıca, bir VM ortamı dahili olarak daha fazla HDD alanına ihtiyaç duyduğunda, bu biraz zor olabilir ve bir tane oluşturmanız gerekir. Dosya boyutu bir sorun olmasa da, normal bir DSL bağlantısında 5Go üzerinden göndermeniz gerektiğinde internet hızı hala darboğaz haline gelir.


2

Çoğu sistemde (diller, çalışma zamanları veya işletim sistemleri) yazılım ve yapılandırmalar yüklemek için standartlaştırılmış bir yöntem vardır, bu nedenle bunları kullanmayı deneyin. Gibi:

  • Java için Maven veya Gradle
  • Perl için CPAN
  • RedHat / Fedora için rpm
  • Linux için dpkg / apt-get
  • Windows için MSI paketleri

Ardından, tam olarak neyin kurulması gerektiğini / hangi adımların gerekli olduğunu açıklayan kurulum talimatlarını yapın:

  • Ne kurmayı düşündüğünüz hakkında kısa talimatlar verin (temel işletim sistemi, Java / Perl / Python gibi temel çalışma zamanı ...)
  • Gerekli kurulumları gerçekleştiren kısa bir komut dosyası yazın (ideal olarak Maven gibi bir aracın tek bir çağrılması)
  • Bunu yeni bir kurulumda test edin (VM'de olduğu gibi)

O zaman çevreyi yeniden yaratabilmelisiniz ve diğerleri de bunu yapabilmelidir (bu solo bir proje değilse önemli olabilir).

Gerekli kurulum paketlerini bir yerde saklamanız gerekebilir veya indirme talimatlarını dahil edebilirsiniz (sistem apt-get veya Maven gibi bunları takip etmediği sürece). Bu, paketlerin sağlayıcılarına ne kadar güvendiğinize bağlıdır - muhtemelen temel Debian paketlerini depolamaya gerek yoktur, ancak bazı küçük ücretsiz yazılım projelerinde iyi bir fikir olabilir.

VM çözümü de çalışır ve kısa vadede muhtemelen daha az iştir (sadece VM'yi saklayın). Ancak bu çözümün, örneğin çevreyi değiştirirken daha fazla esneklik sunduğunu hissediyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.