Sürüm kontrolünü nasıl yaptığımızla ilgili bir sorun mu var?

İş analisti olarak bir programcı ekibi ile çalışıyorum. Ürünümüzün 2.0 sürümünü henüz piyasaya sürdük ve 3 ay içinde piyasaya sürülecek bir sonraki sürüm üzerinde çalışıyoruz (dahili bir yazılım ürünüdür). Maalesef, sürüm 2.0'ın düzeltmeleri gereken bazı sorunlar var ve bu düzeltmeleri birkaç hafta içinde dağıtacağız. Sorun şu ki, üzerinde çalışılmakta olan ve 3 ay daha serbest bırakılmayacak değişiklikleri değiştirmek istemiyoruz.

Programcılar bunu yönetmenin yolunun yalnızca kusur kodlarının kontrol edileceği ve yeni geliştirmelerin kodlarının tamamlanana kadar geliştiricinin yerel makinelerinde tutulacağına karar verdi. Test etmek için makinelerinde yerel yapımlar elde etmek zorunda kalacağım çünkü kodu kontrol ederse ve hataları düzeltmek için başka bir yamayı zorlamak zorunda kalırsak, bu geliştirmeleri henüz eklemek istemiyoruz. Aynı zamanda, aynı kod dosyasının hem hata düzeltmelerini hem de geliştirmeleri içerdiği bir sorun var, bu nedenle kod dosyasını yerel olarak kopyalamak, sonra bir hatayı düzeltmek için bir değişiklik yapmak ve bunu kontrol etmek için bir değişiklik yapıp ardından donanım geliştirme çalışmalarına devam etmek zorunda kalıyorlar. yaptıkları yerel kopya.

Çok sarsılmış görünüyor - bu tür bir senaryoyu ele almanın daha iyi bir yolu var mı? Team Foundation Server ve Visual Studio 2010 kullanıyoruz.

V2.0'da kullandığımız, yayınlandığında bir "sabit durum şube" (Performansı TFS kullandık) olarak adlandırdık. Bu dalda v2 için herhangi bir düzeltme yapılmış ve daha sonra v3 özellikleri üzerinde çalışılırken v3 geliştirme dalına geri gönderilecektir, yani v2'deki bir kusur v3'te de bir kusur ile sonuçlanacaktır.

Değişikliklerin geliştiricinin makinelerinde uzun süre kalması büyük olasılıkla entegrasyon kabusu ile sonuçlanacaktır.

Genelde 'dallanma' etiketi ile kapsanan , her biri kendi yararları ve dezavantajları olan bu tür sorunlarla başa çıkmanın birçok yolu vardır .

Fakat geliştiricileriniz tarafından seçilen yaklaşım ... gee yanlış yazmamamı sağlamak için sözlü olarak alıntı yapacağım ...

kodu ... tamamlanana kadar geliştiricinin yerel makinelerinde tutulacak ...

... yukarıdaki gibi, muhtemelen tamamen yanlış olan tek kişi budur!

Suçluyu sınırlandırmamı sağlayan şey, TFS için, mükemmel, anlaşılması kolay, Microsoft Team Foundation Sunucu Branş Rehberliği - her tür farklı proje için özenle hazırlanmış ve açıklanmış dallanma stratejileri önerileri içeren büyük ve ayrıntılı bir belge ( HTML sürümü). burada ).

1. Geliştirici sürümünüzün nasıl kullanılacağına dair temel bir yanlış anlama var.
2. “Doğru” versiyon kontrol yazılımı hakkında bir tartışma yapmayın. Sorun bu değil.
3. Her kod ayarlaması sorunu düzeltmeyi zorlaştırıyor.
4. Siz doğru olanı yapmaya karar verdiğiniz zaman, bazı şeyleri düzeltirken kod değişikliklerine devam edemezsiniz. Tüm gelişmeleri durdurmalı ve kodu sürüm kontrolüne almalısınız.
5. Dev , en azından oturup konuşabilecek kadar acı çekiyor olmalı .
6. Tüm sürüm kontrol yazılımı temel kavramları destekler:
   • ALL kodu sürüm kontrol havuzuna gider.
   • Tüm kod dosyalarının sürüm numaraları vardır. Bu numaralar kod tekrar kontrol edildiğinde otomatik olarak artar.
   • Bir TAG (ve a) belirli bir sürümünün tüm kod dosyalarını işaretler. Böylece, örneğin yazılımın sürüm 1 sürümünü TAG yapabiliriz.
   • bir ŞUBE ana bagajdan bir "dönüş" tir .
     • Bir dalda yapılan tüm değişiklikler, gövdeyi etkilemez.
     • İsteğe bağlı olarak, şube değişikliklerini bir noktada ana ana hatta yeniden birleştirebilirsiniz .
     • Böylece “iyi şeyleri” karıştırmaktan korkmadan deney yapabiliriz.
7. Sizin dediğim gibi sürüm kontrolünü "inanç atışı" olarak almalısınız. Temel kurallara uymanın işleri yoluna sokacağına GÜVEN. Deneyimsizlik aksi halde düşünmemizi sağlar, güven bana.
8. İşte iyi bir eğitim. Bir sürü başka kaynak taramanız gerekmeyecek kadar genel ve eksiksiz
   • Sürüm Kontrolü, Daha İyi Anlatılanlar

Düzenle

• Çalışma bilgisayarınızda sürüm kontrolü yapın.
  • Bunu şu anda yapabilirsiniz w / out takım koordinasyonu
  • Ekip sürüm kontrolü ile bile, bunu şiddetle tavsiye ederim
  • Ekibiniz Git veya Mercurial kullanıyorsa, bağımsız bir yerel depo kullanıyorsunuzdur. Dağıtılmış sürüm kontrolü bu şekilde çalışır.
  • Ekibinizden farklı VC yazılımı kullanabilirsiniz. Ekibimiz Subversion kullanıyor, yerel olarak Mercurial'ı kullanıyorum. VC yazılımı meta dosyaları (".svn", ".mg", gizli klasörler) çakışmaz.

Fiili bir ekip deposu olarak hareket etmiyorsunuz. Kendi çalışmanızı yönetmek, çabaları yeniden düzenlemek vb. İçin ve takım olarak kendinizi CYAing yapmak FUBAR'ın temelini oluşturmaya devam ediyor.

düzenlemeyi bitir

Tanımladığınız şey sürüm kontrolünü kullanmanın korkunç bir yoludur. Sürüm 2.0 için yapılmış bir dal veya bir etiket veya bazı tanımlayıcılar olmalıdır. Bu şekilde, bu sürümde yapılacak değişiklikler içerilebilir ve daha fazla gelişme gerçekleşmeye devam edebilir.

Bu makale size bazı fikirler verebilir. gitAkılda yazılmıştır , ancak onunla da çalışamamaları için hiçbir sebep yoktur mercurial. Bunların ikisini de kullanmadığınızı fark ediyorum, ama bu aynı zamanda düzeltmeyi düşünmeniz gereken bir problem.

Hızlı Yanıt: Gelişme takımı olmalı ayrı Üretim dalı ayrı dağıtılan kod tabanı V2.0 tutmaya Ana gövde.

Tüm hata düzeltmelerinin önce o dalda yapılması ve daha sonra kodu senkronize etmek için sınanıp diğer dallara dağıtması gerekir .

Projenizde Prod, Staging, QA ve Dev (bazen UAT) for health developmentgibi ortamlar da bulunmalıdır . Bu ortamlar Üretim sürümüne geçmeden önce kurulmalıdır .

Sonuç olarak, hatalara ve değişikliklere hazır olmak, yayınlanmış bir uygulamayı desteklemenin yoludur.

TFS'nin sürüm kontrolü olarak belirtildiği gibi, sağlık geliştirme ortamlarını belirlemek için yardımcı olacak makale listesi de derledim:

• Team Foundation Server'ı küçük bir geliştirme ekibiyle uygulama
• TFS Entegrasyon Platformu'na Hoş Geldiniz!
• TFS Kılavuzuyla Takım Geliştirme
• Geliştirme Ortamı Kurma

Hayır, çünkü bir VCS kullanırken sürüm kontrolü yapmıyorsunuzdur.

Sürüm kontrolü için temel kavram zaman içindeki farkı izlemektir, bazı farkları kaydetmekte PLANLAMA yapıyorsunuz, ancak şu anda değişikliklerin çoğu kaydedilmiyor.

Diğerlerinin dediği gibi, dalları kullanmanız gerekir. Bu kurulumu yaptıktan sonra, tüm işlevsel değişiklikleri kontrol etmelisiniz (ör. Her tuş vuruşunu değil, ancak bir hatayı düzelttiğinizde, bir özellik eklediğinizde, bir özelliği silmeniz veya başka şekilde bir şekilde bir değişiklik yapıp çalışması için).

Ben bir geliştiriciyim ve mevcut sürüm düzeltmeleri için farklı dal kodu ve db ile geliştirmeler için ve daha sonraki ardışık sürüm için farklı bir kod veriliyor.

Düzeltmelerimiz bittikten sonra üretimle birleştirilir ve dağıtılırsa, geliştirmelere tekrar geri dönecek yeni bir taze dal alırız.

Dahası, şu anki sürümüm için 10 düzeltmem varsa gibi bir uygulamayı takip ediyoruz.

Olarak yazarım

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Benzer şekilde diğer düzeltmeler için de sadece bunu değiştirdiğim veya sabitlediğim her satır için yapıyorum. Ve sadece karşılaştır ve taahhüt et. Benzer şekilde aynı dalda paralel yapıyorlarsa kullanabilirler

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+F//Start Iteration 2, Fix No-1, Branch No-"ABC" tüm çözümde arama yapmak için komut ve tür , kesin konumlar, kodun değiştiği dosyalar ve sadece o kısmı işlemek için kullanılabilecek yeni kodlar bulmak için çok yardımcı olur.