Küçük bir şirketin (15 geliştirici) yönetilen kaynak / sürüm kontrolünü kullanmaması olağandışı mıdır? [kapalı]

Bu gerçekten teknik bir soru değil, ancak kaynak kontrolü ve en iyi uygulama hakkında burada başka birkaç soru var.

Çalıştığım şirket (adsız kalacak) kaynak kodunu ve serbest kodunu barındırmak için bir ağ paylaşımı kullanıyor. Yayımlanıp yayımlanmadığına ve hangi sürümün ne olduğuna bağlı olarak kaynak kodunu manuel olarak doğru klasöre taşımak geliştiricinin veya yöneticinin sorumluluğundadır. Dosya adlarını ve sürümlerini kaydettiğimiz yerlerin ve nelerin değiştiğinin etrafına noktalı çeşitli elektronik tablolarımız var ve bazı ekipler ayrıca her dosyanın en üstüne farklı sürümlerin ayrıntılarını da koyuyor. Her takım (2-3 takım) bunu şirket içinde farklı şekilde yapıyor gibi görünüyor. Tahmin edebileceğiniz gibi, organize bir karmaşa - organize, çünkü "doğru insanlar" eşyalarının nerede olduğunu biliyorlar, ama karmaşa çünkü her şey farklı ve her seferinde ne yapacağını hatırlayan insanlara güveniyor.

Bir süredir bir tür yönetilen kaynak kontrolünü zorlamaya çalışıyorum, ancak şirket içinde bunun için yeterli destek alamıyorum. Ana argümanlarım:

• Şu anda savunmasızız; Herhangi bir noktada birileri yapmak zorunda olduğumuz birçok sürüm eyleminden birini yapmayı unutabilir; bu, tüm sürümlerin doğru şekilde kaydedilmediği anlamına gelir. Gerekirse bir sürümü geri almak için saatler veya günler sürebilir
• Hata düzeltmeleriyle birlikte yeni özellikler geliştiriyoruz ve bir kısmı diğerinin serbest bırakılmasını geciktirmek zorunda kalıyoruz çünkü bazı işler henüz tamamlanmadı. Ayrıca müşterileri, sadece bir hata düzeltmesi isteseler bile, yeni özellikler içeren sürümleri almaya zorlamalıyız, çünkü üzerinde çalıştığımız tek bir sürüm var.
• Visual Studio ile ilgili sorunlar yaşıyoruz, çünkü birden fazla geliştirici aynı projeleri aynı anda kullanıyor (aynı dosyaları değil, ancak sorunlara neden oluyor)
• Sadece 15 geliştirici var, ama hepimiz farklı şeyler yapıyoruz; hepimizin izlemesi gereken şirket çapında standart bir yaklaşıma sahip olmak daha iyi olmaz mıydı?

Benim sorularım:

1. Bu büyüklükteki bir grubun kaynak kontrolünün olmaması normal mi?
2. Eğer önereceğim nedenleri - Ben şimdiye kadar kaynak kontrolünün olmaması için sadece belirsiz nedenler verilmiş olabilir için geçerli değil yukarıdaki bilgiler göz önüne alındığında, kaynak kontrolü uygulayan?
3. Başka bir sebep var mıdır için benim cephanelik eklemek olabilir kaynak denetimi?

Esas olarak neden bu kadar direnç gösterdiğime dair bir fikir edinmek istiyorum, bu yüzden lütfen dürüstçe cevaplayın.

En dengeli yaklaşımı benimsediğine ve her üç soruyu da cevapladığına inanıyorum.

Şimdiden teşekkürler

1. Bu normal olmayabilir , ancak Treb'in dediği gibi , muhtemelen alışılmadık bir durum değil.

2. Diğerlerinin de dediği gibi, büyüklüğünüzdeki bir şirkette kaynak kontrolünün olmaması için geçerli bir neden yoktur . Bu nedenle geçersiz nedenleri tanımlamanız ve bunlara saldırmanız gerekir :

   a) Asıl durum statükodur : "Bozulmadıysa, düzeltmeyin". Bu zordur: İşe yaramadıklarının yanı sıra çalışmadıklarını belirtmeye başlayabilirsin (ki bu sizi hızlı bir şekilde 'olumsuz kişi' olarak etiketleyebilir) ya da sadece bir şeyin patlamasını bekleyebilirsin (asla ) olur, yoksa her şeyi vurgulamak olabilir olabilir yanlış. Maalesef küçük şirketler sorumlu insanlar aslında dek 'yanlış gidebilir şeyler' nispeten geçirimsiz olan do yanlış gidebilir ...

   b) cehalet / korku / belirsizlik : “kaynak kontrolünün ne olduğunu gerçekten bilmiyoruz; nasıl kullanacağımızı bilmiyoruz, hangi aracı seçeceğimizi bilmiyoruz; tarzımızı sıkıştıracak” . Bu kesinlikle bir nedeni olmaz gönderebilirsiniz burada! Tek başına sizin için oldukça yüksek bir sipariş olabilir, ancak bence çok fazla değişken veya alternatif değil, 'anahtar teslimi' bir çözüm sunma ihtimalinizi en üst seviyeye çıkarmak için bence. Açık bir fikre ihtiyacınız var: Çalışma sürecinizi verilen aletle çalışmak için nasıl yerleştirmek / dönüştürmek istediğiniz; Mevcut kodu nasıl yedeklemeyi planladığınızı / kullanıcıları ne kadar hızlı eğitebileceğinizi ve çalıştırıp çalıştırmalarını sağladığınızı düşünüyorsunuz; Geçiş periyodunu nasıl yönetebilirsiniz (varsa); 'maliyet' ne kadar muhtemeldir (dolar olarak değilse saat cinsinden).

   c) başka sebepler olabilir (örneğin VSS ile ilgili önceki kötü deneyimler veya aşırı karmaşık araçlar hakkında 'korku hikayeleri' okumuş), ancak bunları keşfettiğinizde bunları tek tek vurmanız gerekir.

3. Diğer cevaplarda ana hatlarıyla verilen kaynak kontrolünün çok fazla nedeni vardır . Tavsiyem, şirketinize gerçekten fark yaratabilecek ana 2 veya 3'ü seçip onları parlatmak ve mümkün olduğunca çok sayıda iş arkadaşınızla bir toplantıda sunmak olacaktır. Tartışmayı kışkırtmaya çalışın: onları derhal ikna etmeseniz bile, yapışma noktalarının ne olabileceği konusunda fikir edineceksiniz.

( Değişim İşlevi hakkında okudunuz / duydunuz mu?)

Kaynak kontrol etmeden çalışan bir grubun kaynak kontrolü olmadan çalışabilmesi kesinlikle normal değildir; kaynak kontrol etmeden etkili bir şekilde çalışabilen en büyük programcı grubunun büyüklüğü bir veya daha küçüktür. Bu var kesinlikle affedilmez profesyonel ekibi için versiyon kontrolü olmadan çalışmak herhangi boyutu ve belki de yaratıcı hissetmiyorum ama bunu vazgeçmek istemesi için herhangi bir nedenden ile gelip olamaz.

Sürüm kontrolü sadece başka bir araçtır - özellikle güçlü ve en düşük maliyete göre muazzam faydalar sağlayan bir araçtır . Dallanma, otomatik birleştirme, etiketleme ve benzeri her türlü başka kullanışlı şeyle, tüm değişikliklerinizi organize bir şekilde hassas bir şekilde yönetme gücü sunar. Eğer sayısız versiyonları önce bir sürüm oluşturmak için gerekiyorsa, zaman içinde bu noktadan kodunu kontrol edebilir sadece inşa başka çemberler üzerinden atlamak zorunda kalmadan.

Daha da önemlisi, bir hata düzeltmesi yazmanız gerekirse, üzerinde çalıştığınız yeni özellikleri sunmak zorunda kalmadan bir güncellemeyle birleştirebilirsiniz - çünkü başka bir daldadırlar ve geliştirme sürecinin geri kalanında ihtiyaç duyduğu kadarıyla endişeli olun, henüz yoklar.

Direniş yaşıyorsun çünkü şirket kültürüne meydan okuyorsun. Ne söylediğiniz önemli değil, uyum sağlamaları zaman alacak. Yapabileceğiniz en iyi şey, onu zorlamaya devam etmektir ve şirket gerçekten bütçeye girmiyorsa, geliştirici olarak seviyenize daha uygun başka bir iş bulun.

Bu büyüklükteki bir grubun kaynak kontrolünün olmaması normal mi?

Tecrübelerime göre, bu norm değil, ancak buradaki diğer cevapların önerdiği kadar sıradışı değil. Küçük şirketlerin çoğunluğu kaynak kontrolü kullanıyor, ancak önemli sayıda maalesef kullanmıyor.

Şimdiye kadar kaynak kontrolüne sahip olmamam için belli belirsiz nedenler verildi - yukarıdaki bilgiler göz önüne alındığında, kaynak kontrolünü uygulamamak için hangi nedenlerin geçerli olacağını önerirdiniz?

İyi bir tartışma için SO'da bu soruya bakın . Kabul edilen cevap şöyle diyor:
"Sürüm kontrolünü kullanmamak için iyi bir neden yok. Bir değil."

Kaynak kontrolünün cephaneliğime ekleyebileceğim başka nedenler var mı?

Karşılaştığım tüm geliştiriciler ve proje yöneticileri arasında ve tabii ki burada Programcılar ve SO üzerinde fikir birliği var. Bu kabul edilmiş bir en iyi uygulamadır . Biri bunu görmezden gelmeye karar verirse, bunun neden onun için doğru karar olduğu konusunda çok güçlü ve ikna edici argümanlara sahip olması gerekir (yani 'asla ihtiyaç duymadığımızdan, neden gelecekte buna ihtiyacımız var'). Şimdiye kadar vermiş olduğunuz argümanlar belirli konulara odaklanmıştır, belki de 'herkes yapar, o yüzden neden biz de yapmıyoruz?

Kaynak kontrolü, tek bir geliştirici ekibi için bile iyidir. Herhangi bir kaynak kontrol sistemi temelde değişiklikleri takip eden bir sürüm kontrol sistemidir. Bazı kodları kaldırmış ve kodun artık gerekli olduğunu düşünen tek bir geliştirici düşünün. Eski kodu geri alabilir mi?

Sadece size yardımcı olacak bir araç için gidin. Boyut her yerde önemli değil. Kalite her yerde önemli.

Zaten bir sürüm kontrol sistemi kullanıyorsunuz, ama çok iyi bir sistem değil. İnsanlar zaten ihtiyaç sürümü kontrolünü tanıyor gibi görünüyor. Sadece onları bir sonraki seviyeye tanıtmanız gerekiyor - yazılım sürüm kontrolü.

Ben olsaydım, SCM'yi zaten yaptıklarının gelişmiş bir sürümü olarak tanıtırdım. İyi bir alet kullanmanın sürmekte olan işlerin çoğunu nasıl otomatikleştireceğini vurgulayacağım.

• Bir elektronik tablodaki değişiklikleri kaydetmek yerine, SCM sistemi yalnızca neyin değiştiğini değil, neyi değiştirdiğini ve nedenini takip eder.

• Bir bonus olarak, kodun hayatındaki herhangi bir noktaya geri dönebilir ve gerçekte orada ne olduğunu görebilirsiniz.

• Farklı klasörlerde farklı kod sürümleri bulundurmak ve bir değişikliği taşımak için klasörler arasında şeyleri taşımak / birleştirmek zorunda kalmak yerine, her şeyi aynı yerde tutabilir ve (daha da önemlisi) aracın birleştirmeyi yapmasına izin verebilirsiniz.

Diğerlerinin de söylediği gibi, biraz direnç beklerdim, bu yüzden yaptığım şeyler üzerinde sistemi kullanarak prototiplerim.

(BTW, Özgeçmişimi ve diğer belgelerimi gerçekten SVN altına koydum. O zaman yine Yapılandırma ve Entegrasyon Yöneticilerinin rollerini birkaç kez oynadım.)

Eğer önereceğim nedenleri - Ben şimdiye kadar kaynak kontrolünün olmaması için sadece belirsiz nedenler verilmiş olabilir için geçerli değil yukarıdaki bilgiler göz önüne alındığında, kaynak kontrolü uygulayan?

• Geliştirdiğiniz ürün bir sürüm kontrol sistemidir; yöneticiler, mevcut ürünlerin yeni ürünün tasarımını ve uygulamasını etkilemesini önleme konusunda endişeli.

• BASE’in haftasonları arasında boğalarla zıplayan ve koşan, heyecan arayan menajerler, her şeyin henüz cehenneme gidip gitmediğini düşünmek için araba sürmekten hoşlanıyorlar.

• Düşmanca devralmaları önler. Kim bu şekilde yönetilen bir yazılım geliştirme kıyafeti edinmek ister ki?

Kaynak kontrolünün cephaneliğime ekleyebileceğim başka nedenler var mı?

• Zaten sürüm kontrolü yapıyorsunuz, ancak şu anda hayal edilebilecek en az verimli, en fazla emek harcayan, en hataya açık şekilde yapıyorsunuz. Bir VCS kullanmak paradan tasarruf etmenizi, zaman kazanmanızı ve kalitenizi artırmanızı sağlar.

• Disk alanı kazandırır. Çoğu sürüm kontrol sistemi sadece dosyalar arasındaki deltaları korur. Şu anda, her dosyanın her sürümünün tam bir kopyasını kaydediyorsunuz. (Tüm bu kopyaların yedeklenmesi çok zaman ve alan gerektirmelidir!)

• Birkaç geliştirici aynı dosya üzerinde aynı anda çalışabilir ve çok fazla sorun yaşamadan farkları uzlaştırabilir. Bir VCS olmadan değişikliklerin birleştirilmesi elbette mümkündür ancak bu durumda neyin, neyin ve niçin değiştiğini izlemek neredeyse imkansızdır.

• Geliştiricilere istedikleri zaman istedikleri süreyi kurtarabileceklerini bilerek yeni fikirler denemede özgürlük verir.

• Daha iyi süreç, yetenekli geliştiricileri işe almayı ve elde tutmayı kolaylaştırır.

Bu büyüklükteki bir grubun kaynak kontrolünün olmaması normal mi?

Hayır kesinlikle olmaz. Şu anki şirketime başladığımda, değiştirilmiş kodunuzu göndermeniz gereken bir kişi vardı ve o da birleştirecek. Gün içinde herkesi SVN kullanmaya ikna edebilirim .

Şimdiye kadar kaynak kontrolüne sahip olmamam için belli belirsiz nedenler verildi - yukarıdaki bilgiler göz önüne alındığında, kaynak kontrolünü uygulamamak için hangi nedenlerin geçerli olacağını önerirdiniz?

Bence sadece belirsiz sebepleri duymanızın nedeni, sürüm kontrolünü kullanmamak için geçerli bir neden olmamasıdır.

Kaynak kontrolünün cephaneliğime ekleyebileceğim başka nedenler var mı?

Evet, birçok neden var.

1. Dallanma, diğer gelişmelere müdahale etmeden size yeni fonksiyonlar geliştirme imkanı sunar.
2. Her bir taahhüt size tam olarak neyin değiştirildiği, bu değişikliği kim ve ne zaman yapıldığı hakkında bilgi verir.
3. Kolayca hata düzeltmeleri yapabilir ve bunları müşterilere dağıtabilir ve bitmemiş yeni işlevleri bırakabilirsiniz.
4. Müşteriler daha yeni bir sürüme geçmekten korkuyorsa, farklı sürümleri koruyabilirsiniz.
5. Aynı proje üzerinde (aynı kaynak dosyalar bile!) Kolaylıkla çalışabilirsiniz.
6. Bir yanlışlıktan sonra değişiklikleri koruyarak kolayca bir hatayı geri alabilirsiniz.

Bazı insanlar, statükonun kendileri için daha iyi bir şey görene kadar statünün ne kadar kötü olduğunu fark etmekte zorlanıyorlar. İhtiyacın olan iyi bir demo . Geliştirebileceği bazı gerçek görev örneklerini göster. “Bu, mevcut sistemimizi izlemem için 4 saatimi aldı, ancak bu bir kaynak kontrol komutu bana derhal söyledi.”

Kaynak kontrolünü kullanmamak, yalnız bir geliştirici için bile sorun istiyor. Hiçbir şeyi kaybetme riski olmadan acımasızca düzenleyebildiğiniz basit gerçek, haftalar veya günler içerisinde öğrenme çabasını telafi eder.

Bununla birlikte, yöneticilerinizi kaynak kontrolü sağlamaya ikna edemiyorsanız, kendinize bir iyilik yapın ve en azından yerel olarak yerel veya yerel bir şey gibi bir şey kullanın - kaynak kontrolü yetersizliğinden dolayı işler patlarsa, en azından Bunu yapan kişi.

Şirketim sürüm kontrolü için GIT kullanıyor. Şirket bir geliştirici, bir CEO, bir güvenlik görevlisi, bir temizlikçi ve bir emircidir. Hepsi benim. Kaynak sürüm kontrolü her zaman bir zorunluluktur.

Tek başıma birçok proje üzerinde çalışıyorum ve hala sürüm kontrolünü kullanıyorum. Boyut önemli değil. Her zaman sürüm kontrolüne sahip olmanıza yardımcı olur.

Joel Testinde 1 numara olmasının bir nedeni var: http://www.joelonsoftware.com/articles/fog000000000043.html

Ayrıca, listede # 2 ve # 3 'ü mümkün kılar.

Birkaç yıl önce 6 kişilik bir ekiple benzer bir pozisyondaydık. Geliştiricilerden biri, paylaşılan klasörün bulunduğu dev sunucuya SVN yükleme adımını attı ve kullanmaya başladı.

Herkes davayı izledi ve CI ( CruiseControl ) uygulamasını uygulamadan ve otomasyon ve kalite kontrollerini içerecek şekilde yapım ve sürüm sürecimizde devrim yapmadan çok önce değildi .

O NE LAN?! Bu şimdiye kadar gördüğüm en saçma soru olabilir. Yeni bir iş bulmalısın. 15 geliştirici ?! Sence bu küçük bir takım mı? Bu çılgınlık. Yönetici derhal sonlandırılmalıdır. Dürüst olmak gerekirse, bu soruyu okuduktan sonra kabus göreceğim. Lütfen bize sattığınız ürünü söyleyin, böylece satın almamaya çalışın! Neyin korkutucu olduğunu, bu soruyu ya da bunun olağandışı olmadığını söyleyen cevapları bilmiyorum!

15 geliştiricinin herhangi bir kaynak kontrolü olmadan nasıl çalışabileceğini hayal edemiyorum. Ancak, şundan:

(...) kaynak kodunu barındırmak için bir ağ paylaşımı kullanıyor (...)

Sanırım kendi zavallı adamınızın VSS gibi versiyon kontrolünü yarattığınızı (aynı zamanda paylaşılan klasöre dayanarak) yarattığınızı düşünüyorum . Riskli ve verimli değil.

Patronunuza ne kadar kötü olduğunu açıklayın, 2 günlük bir SVN veya GIT eğitimine yatırım yapın ve kodunuzu hala makul bir şekilde tutarken gerçek sürüm kontrol sistemini kullanmaya başlayın.

Günde birkaç kez işlem yapmazsam veya en azından evden ayrılmadan önce, bir şeyler eksik, yanlış şeyler gibi hissediyorum.

Bir keresinde 1998'de sadece 2 geliştiricili (ben + uzun saçlı yönetici adam) bir şirkette çalıştım. O zaman bile svn kullandık. Sadece çok uygun.

Kariyerimde birkaç kez bir iş günü kaybettim çünkü cp yerine mv ve sonra rm -rf gibi bir şey yaptım. Ağladım ve şehir sokaklarında umutsuzluğa dolaştım.

13 yıl boyunca SE’de bulunduğum 5 şirkette çalıştım, bazı konferanslarda bulundum ve sürüm kontrolünü kullanmayan bir şirketle hiç karşılaşmadım.

Ancak en sevdiğim iç tasarım şirketi 20 çalışan, proje yönetimi + işbirliği için beyaz tahta kullanıyor. Düzlüğünü yanlış biliyorlar, ancak yükseltme için zaman bulamıyorlar. Her nasılsa olsa çalışır. Bana nasıl olduğunu sorma.

Lider olmak. Lider olmak, doğru olanı yapmak anlamına gelir; proaktif olarak problem çözme. Liderlik hiçbir şey yapmıyor çünkü yeterince fikir birliği yok. İyi bir lider, ne zaman bir fikir birliği oluşturması ve ne zaman yapılması gerektiği durumlarını tanımayı öğrenir. Bu açıkça bir durumdur. Kod kontrolü eksikliği WIL, er ya da geç yüzünüze patlayacak.

Liderler genellikle resmi yönetim pozisyonlarında değildir. İnsanlar unvanı ne olursa olsun iyi ve kararlı liderleri takip edecekler.

Kararlı çabalarınız düşerse, özellikle yönetimden geliyorsa, oradan kurtulmanızın açık bir işareti. Mesleki gelişiminizde bir kayma; Yetkili geliştiriciler ve yetersiz yönetim karışmaz ve iktidarsız bir beceriksiz sizi mahveder.

Tamam, geri dönüşler bana geliyor. Oturumu kapatma. İyi şanslar.

1. Bir kronometre bul
   • Yalnızca sürümleri senkronize etmek için e-tabloda harcadığınız zamanı sayın
   • Bozuk sürümleri onarmak için harcadığınız zamanı sayın
   • insanların koridorda bağırma sayısını " şu anda başka kimsenin olmadığından emin olmak için main.c! ' i düzenliyorum!" .
   • Müşterilerinden aldığınız şikayet sayısını sayın, çünkü düzeltmeleri başka değişiklikler içeriyorsa
   • sürümleri senkronize edemediğiniz için sürümün gecikme süresini sayın
2. Bu verilerle bir powerpoint yapın, vcs'nin nasıl çalıştığını karşılaştırın.
3. Göster yönetimi

Bu sadece gerçekleşmeyi bekleyen bir kaza. Kod geçmişiniz yok ve bir tanesinde baskın düştüğünde, geliştiricilerinizden biri aylarca çalışmayı kaldırabilir. Küçük bir şirket olarak, bu tür bir aksaklık göze alamaz.

Ayrıca bu paylaşım sürücüsüne çok maruz kalıyorsunuz. İyi bir yedek bile olsa, çalışmamanın ne kadar zamanını kaldırabilirsin. 1 saat, 1 gün, 1 hafta. Yeni bir sunucunun kurulması, yedeklemenin geri yüklenmesi, vb. Yapılması ne kadar sürer? Yine küçük bir şirket olarak beklemede ekstra bir donanıma sahip değilsiniz ve hızlandırılmış nakliye vb.

Site dışı depolamayı da düşünün. Bir sel veya yangın pek olağandışı değildir. Binada saatler sonra yangın çıkması durumunda ne olur? Kaç aylık iş kaybedilecek? Github gibi yönetilen bir kod deposu bunun için değerli olacaktır. Barındırılan bir hizmette basit bir SVN sunucusu kullanmak bile bu alanda bir adım daha yükselir.

LordScree, sizin gibi neredeyse aynı bir durumdayım, acil ekibim yaklaşık 15 geliştirici. Kaynak kontrolünün kullanılmadığı konusunda (neredeyse dehşet içinde) inancıyorum. "Kaynak kontrolü kullanmalıyız" a ilk cevabım "uygulamak için zamanımız yok" oldu. Bana göre, iç çamaşırı giymek gibi, kaynak kontrolü isteğe bağlı değildir. Birkaç ay sonra, org tarafından seçilen TFS'yi uygulama iznim de var; çünkü MS ve 90 günlük deneme süresine sahip. Alt satırda, onlarsız bir şekilde kıkırdayarak kaynak kontrolüne ihtiyaç duyan bir organizasyonu ikna etmek çok zordur. Geliştiricilere, dosyalarınızı veya özellikle de yedeklenmiş dosya adındaki bir tarihi olan dosyaları yedeklediğiniz zaman, kaynak denetimine ne zaman bir şey koyacağınızın bir örneği olduğunu söylüyorum. Yaparım Sizin için mükemmel cevaplar yok, ama bunun çok nadir olduğuna inanıyorum. Aynı savaşta savaşıyorum ve ilerlemeni açık tutacağım. Ve umarım başka bir yere bakabilirim çünkü kaos içinde çalışamıyorum!

3 geliştirme ekibimiz var ve kaynak kontrolü kullanıyoruz. Kişisel projelerimde bir geliştiricim var ve kaynak kontrolü kullanıyorum. Bu sadece takım yönetimi için değil, bir şeyi mahvetmek için yaptığınızdan korkmadan deneysel bir işe girebilmek için de faydalıdır.

Yönetimi ikna etmenin en kolay yolu? Genel ürün için daha az risk var ve uzun vadede geliştirici verimliliğini artıracak. Her ikisi de aynı şekilde doğrudur ve her ikisi de yöneticilere hitap eder.

Hiçbir şekilde normal bir senaryo değildir ve bence bu kurumu şirketinize almak için zorlu bir mücadele vermelisiniz. Kıyamet gününe yaklaştığınız zaman çok geniş kapsamlı faydaları vardır ve aynı şeyi anlamalarının hiçbir anlamı yoktur ve kırılan bir durum söz konusu değilse Kırılmazsa düzeltmeyin

Uygulamamak için herhangi bir sebep, sadece kötü iş için bir bahane veya gerçekleşmeyi bekleyen bir gaf olabilir.

Sadece onlara uygulamanın ne olduğunu bulmak için ne kadar harika olduğunu söyleyin.

hakkında nasıl hey bu işlevsellik Mart ayında eklendi ı biz biraz daha bu konuda genişletmek gerektiğini düşünüyorum.

Vay canına bu hata 154256 bu taahhütte düzeltildi.

Uygulamayı dallandırabilir ve konuşlandırmayı gönderebilirim.

Bu devam edip gidebilir ... (daha sonra başka bir soru olarak gelecek olan emirlere yorum eklemeyi unutmayın)

Tek kodlu projelerim ve aynı anda aynı kod üzerinde çalışan 30-40 kişinin çalıştığı iş projelerim için sürüm kontrolü kullanıyorum. Sürüm kontrolünün örgütsel avantajları vardır, ancak dosyaları ve saklama değişikliklerini geri alma yeteneği gerçekten kod yönetmenin baş ağrısına neden olabilir ... ve sonunda bir programcı için en iyi senaryodur, bu yüzden kodlamaya odaklanabilirler.

Sürüm kontrolü kullanmamayı destekleme nedenleri oldukça sınırlıdır. Tek düşünebildiğim şeylerin teknik yönü.

• Tüm personelinizin iş akışını uygun maliyetli bir versiyonlama sistemi içerecek şekilde dönüştürmek için çok fazla öğrenme eğrisi var.
• Proje yöneticiniz ek yükü, bir depoyu yönetme ve sürdürme iş akışına dahil etmenin faydalı olacağını düşünmüyor. (Öncelikle eski Sürüm Sistemleri ile ilgili bir sorun)

Sürüm oluşturma sistemi kullanmak için birçok neden vardır. En azından etrafta dolaşmayı bırak. Yamalarla çalışın. Sürüm oluşturma sistemleri, tam olarak sizin söylediğiniz şeyi yapabilir.

• Bir sonraki sürümde aynı anda hata düzeltmeleri yapabilir ve ayrı ayrı yayınlayabilirsiniz.
• Dosyaları üzerinde çalışmak için bir konumdan diğerine taşımak yerine, bir dal oluşturabilir ve tamamlandıktan sonra master'ı birleştirebilirsiniz.
• Her geliştiricinin aynı projedeki sorunları birden fazla makinede açmasını önlemek için kaynak kodun kendi kopyası bulunabilir.
• Kazalar, eğer kod ciddi bir şekilde kırılırsa, son çalışma revizyon numarasına geri dönmek için yapmanız gereken tek şey.
• Sürüm kontrolü, hata izci ve sürekli entegrasyon sistemleri ile iyi eşleştirilmiştir.

Şahsen tek kişilik bir ekip olarak versiyonlama, hata izleme, sürekli entegrasyon, kod inceleme, kod tutarlılık kontrolü, birim testi, selenyum testleri, kaynak kod analizi kullanıyorum ve daha fazlasını da unutuyorum olabilir. Kabul ediyorum, hafif bir öğrenme eğrisi var. Ayrıca, otomatikleştirdiğiniz ek adımlar için gerekli olan ek yönetim zamanının bir travması var. Tecrübelerime göre, harcanan çaba, ilave yönetim zamanından daha ağır basıyor.

1990'daki ilk ciddi işimde bölümümde çalışan tek geliştiriciydim ve kaynak kontrolünü kullanmayı bilmiyordum.

Kısa süre sonra öğrendim, o zamandan itibaren, kurdukları ilk şeylerden birini yapmayan bir proje görmedim.

Neredeyse bu işteki tüm işimi kaybettim çünkü yanlış seviyedeki bir klasörü sildim. Neyse ki ben bir hafta önce 5 "diskete bir kopyasını eve getirmiştim ve birkaç uzun gün içinde hafta çalışmasını yeniden yapabildim.

Bu yüzden ekipteki herkes için ilk proje olsaydı ve hiç kimse daha iyisini bilmiyorsa kabul edilebilir sayılırdım, ancak bir kişi gerçekten faydaları açıklayabilseydi ve takım hala dinlemese bile, yeniden kategorize ederim. grubun "saf" den "tehlikeli" olarak yetersiz kaldığı fikrine "(bu kadar yaygın şekilde gösterilen faydaları olan bir araç kullanmaya direnç) neredeyse suçtur - ekibiniz" Derleyiciler "e güvenmiyor ve her şeyi meclis dilinde yapmakta ısrar ediyormuş gibi ).

Bunu çok şey anlattım ... gömülü yazılım / donanım yapan küçük mühendislik / elektronik şirketlerinde.

Bu yerlerde SCM elektronik mühendisliği kültürünün bir parçası değildir. Genellikle proje başına bir mühendisi var, sadece en son sürümü yedeklemesi gerekiyor.

Bu nedenle dallanma / birleşme ve hatta kod paylaşımı bile önemsiz olarak kabul edilir. Ayrıca, bu şirketler muhtemelen ISO 9000'dir, bu nedenle garip olsa da süreç belgelenmiştir.

Her durumda, ben / diğer geliştiriciler henüz SCM'yi kişisel olarak kullanmaya başladılar.

Çalıştığım yerde aynı sorun var. Şu an sahip olduğun sorunları çözmek için kaynak kontrolünü "radar altında" kaydırmaya çalışıyorum. Kişisel olarak geliştirdiğim projeler için fosil kullanıyorum .

Geçenlerde şirket LAN'ına kurulmuş bir fosil sunucusu buldum, bu yüzden şimdi daha da kullanışlı. Direnişe zarar vereceğimi ve bizi ağ klasörlerinin statükonundan uzaklaştıracağım bazı küçük projelerdeki kullanışlılığı kanıtladığımdan eminim.

Fosil kullanmamam için duyduğum en büyük nedenler ya da diğer bazı VCS’ler:

1. “Programcıların” çoğu senaryo çocuğu ve nasıl kullanılacağını anlamıyor
2. Öğrenebilenler, kullanmanın bir sıkıntı olduğunu düşünüyorlar.
3. Bu insanlar eski güvenlik görevlileridir, ağ klasörleriyle rahattırlar, yani herkes olmalı
4. Hiç kimsenin doğru kurmaya vakti yok, ya da nasıl kullanılacağını öğrenecek
5. Özellikler harika olsa da hiçbiri gerekli değil

Gördüğünüz gibi, kullanımının basit, önceden ayarlanmış, öğrenmesi kolay ve özelliklerin tamamen buna değer olduğunu göstererek bunları aşmaya çalışıyorum.

Sonunda, kaynak kontrolünü kullanmalarını sağlayamasanız bile, hepsi bir ağ ağacında. Fosil, ağaçtaki her şeyi sürümlendirebilir ve bir dosya değişikliği gerçekleştiğinde veya en azından her saat başında çalışacak şekilde ayarlayabilirsiniz. Bunu “kaynak kontrolüne ihtiyaç duymayan” bazı projelerimiz için yaptım ve bir şeyler ters gittiğinde iyi bir sürüme dönmeme izin verdi.

Doğru yapın, yaptığınızı bile bilmiyorlar. Öyleyse, kırılmış yapıyı restore eden ve aracınızın ne kadar faydalı olduğunu gösteren kahraman olabilirsiniz .

Artık Git ve Mercurial gibi DVCS araçları mevcut ve kurulumu ve kullanımı inanılmaz derecede kolay olduğu için, kaynak kontrolü kullanmamak için 1 (!) Bir ekip için bile mazeret yok. Takımın büyüklüğü hakkında değil, yeni bir sürümde çalışırken üretim sorunlarının giderilmesi ve kaynak kodun durumunu farklı sürümler için takip etmek gibi değişiklikleriniz hakkında yorumlanmış bir geçmişe sahip olmak ve iş akışlarını destekleme yeteneği hakkında.

Bu boyuta sahip bir takımda bir iş teklif edilseydi ve geliştiricilerden biri VCS kullanmayı önermediyse, ya da "yönetim" onları engellemişse, işi düzeltirdim. Bu, bugünlerde çalışmanın kabul edilebilir bir yolu değil.

Hemen kendinize bir GIT sürüm kontrolü almalısınız. Google Code Project Hosting'den bile kullanabilirsiniz. Diğerleri, bir şeyi el ile kopyalarken yalnızca bir tıklamayla değişiklik yaptığınızı gördüğünde, belki de fikrini değiştirir.

Vay, sadece vay. Kod denetimini ele almanın en iyi yolu olduğunu düşünmemekle birlikte, sıra dışı değil, 6 geliştiricili bir şirkette çalıştım ve hiçbir kaynak denetimi kullanılmadı, dosya yönetimi, yayın yöneticisi ve tüm değişiklikleri neyin gözetmeyeceği. Aslında, mantra, işlevselliğin etrafına bir tür anahtar sarıldığı sürece projelere yeni işlevler eklenebileceği idi.

Örneğin, PHP'de yazılmış bir ab sınıfı sosyal ağ üzerinde çalışıyorduk ve müşteri, bir kullanıcının profiline abone olabilmek için işlevsellik istedi. Temel olarak işlevsellik böyle bir çeke sarıldıysa (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {sonra kodu yürütün}

Çalıştığım yerde hiçbir zaman belirli bir dosya üzerinde çalışan birden fazla geliştiriciye sahip değildi, çoğunlukla her şey modülerdi, bu nedenle bu durumda kaynak kontrolüne gerek yoktu. Ancak, kaynak kontrolünün avantajlarının çoğu durumda buna sahip olmamanın dezavantajlarından çok daha ağır olduğuna inanıyorum.

Şirketinizin dosya değişikliklerini belgeleyen e-tablolara başvurduğu ve Git veya Subversion gibi bir şeyin bunu sizin için halledebildiği zaman neyin değiştiğini görmek gerçekten çok saçma.

Bazıları ikna olmuş gibisiniz, ancak kuruluştaki biri sizi bunu yapmaya yetki vermiyor. Diğer yorumlardan okuyabileceğiniz gibi yapmalısınız.

Burada bazı bilgileri bulabilirsiniz: http://www.internetcontact.be/scm/?page_id=358

En önemli faktör, müşterilerinizin son 'dengesiz' şubeye zorlanması ve müşterilerinizle yaptığınız sözleşmelerin sizi kararsız sürümleri dağıtmaktan sorumlu kılması, şirketinizin para kaybetmesidir. Gerçekten burada sürüm kararlılığına odaklanmalısınız. Bu, kaynak kontrolünün ana nedenidir ve ana başarısızlığınız gibi görünmektedir. Halihazırda alternatif sistemlere sahip olduğunuz için kaynak kontrolünü kullanarak diğerleri o kadar da geliştirilmez.