Subversion / kiểm soát nguồn chỉ cho mã sản xuất?


21

Tôi đã tốt nghiệp đại học ngành Khoa học Máy tính một năm trước, và hiện đang làm việc tại một công ty phát triển web nhỏ (tôi và một nhà phát triển khác, cộng với các nhà quản lý, dịch vụ khách hàng và người thử nghiệm). Cho đến trước khi tôi bắt đầu, không có hệ thống kiểm soát nguồn. Bây giờ chúng tôi đang dần bắt đầu triển khai SVN, nhưng nhà phát triển (cao cấp) khác (từ đó được gọi là Joe) khẳng định rằng mã duy nhất phải được cam kết cho kho SVN của chúng tôi là mã đã được thử nghiệm và được phê duyệt là sẵn sàng sản xuất. Điều đó có nghĩa là, trên các dự án lớn hơn, có thể không có cam kết trong nhiều tuần tại một thời điểm hoặc nhiều hơn.

Đây có phải là một thực tế bình thường? Đối với tôi có vẻ như chúng ta mất rất nhiều lợi ích của việc kiểm soát nguồn, bao gồm:

  • Theo dõi chi tiết tiến độ dự án
  • Theo dõi các vấn đề khi chúng xuất hiện và được giải quyết
  • Dễ dàng đẩy lùi sai lầm
  • Sao lưu mã dễ dàng, vì vậy chúng tôi không mất nhiều nếu máy trạm bị hỏng
  • Dễ dàng hơn để xác định chính xác mã nào đang chạy trong các trang web sản xuất, giả sử chúng tôi đóng dấu sửa đổi vào các tệp thực thi như được mô tả ở đây
  • Hợp tác dễ dàng (mặc dù chúng tôi không thực hiện bất kỳ hoạt động nhóm nào; đó là tất cả các dự án solo)
  • V.v.

EDIT: Tôi nên nhấn mạnh rằng trong lịch sử, không có bất kỳ tinh thần đồng đội thực sự nào trong công ty này; chỉ có hai nhà phát triển làm việc trên các dự án riêng biệt. Ngoài ra, rất nhiều dự án nhỏ, vì vậy chúng có thể được hoàn thành trong một vài tuần. Và công ty đã hoạt động được hơn một thập kỷ và hoạt động tốt mà không cần kiểm soát nguồn. Các dự án thường được hoàn thành trong khung thời gian ước tính của họ.


2
Làm thế nào để anh ấy thúc đẩy ý tưởng này bằng cách này? Nếu anh ấy không cho bạn bất kỳ lý do, bạn đã hỏi?
Anto

8
"Joe" có hiểu phân nhánh không? Một số câu hỏi nhẹ nhàng để tìm hiểu có thể thú vị.
James

2
@Anto - Tôi nghĩ rằng nó được tóm tắt tốt nhất bởi "nó không phải là sản xuất và không nên là một phần của kho lưu trữ sản xuất".
Ông Jefferson

1
@James - Tôi không nghĩ rằng anh ấy biết SVN nói chung rất tốt, vì vậy không, tôi không nghĩ anh ấy biết về việc phân nhánh. Nhưng đưa ra các câu trả lời dưới đây, tôi nghĩ đó là giải pháp.
Ông Jefferson

4
Đọc câu hỏi này và một giọng nói nhỏ trong đầu tôi vừa hét lên "NOOOOOOOOOOOOOooooooooooooo".
Kevin D

Câu trả lời:


1

Nếu các dự án được hoàn thành trong khung thời gian ước tính của họ, có an toàn không khi cho rằng khách hàng là khách hàng hài lòng? :)

Có vẻ như công ty cũng đang bắt đầu thực hiện các loại dự án mới và trải qua một số cơn đau ngày càng tăng hoặc một số "cơn đau thay đổi". Rất nhiều giả định đang diễn ra ở đây ... Hãy chịu đựng với tôi!

Nếu bạn tự tin rằng việc tổ chức và kiểm soát mã có thể giúp bạn và nhóm của bạn trong nội bộ thì SVN nên được xem xét, IMHO. Bạn nhận được điểm thưởng nếu đi tuyến đường này thực sự hoạt động và công ty có thể tạo ra các sản phẩm chất lượng cao hơn do đó làm cho khách hàng hạnh phúc hơn!

Hãy cẩn thận nếu có vẻ như một cuộc đấu tranh với quản lý sẽ tạo ra một môi trường làm việc căng thẳng. Thực tế là các chủ sở hữu đã làm cho công ty. Và không chỉ vậy, họ đã làm nên một công ty thành công. Không có khả năng họ trúng số độc đắc vì họ giỏi đánh bạc.

Hãy tôn trọng và cuối cùng bạn có thể được lắng nghe.

Hy vọng điều này sẽ kết thúc dẫn đến một đội ngũ hiệu quả hơn và hạnh phúc hơn. Theo kinh nghiệm của tôi, đó là khó khăn để có được với quản lý thất vọng.


42

Joe đã chết khá nhiều. Bây giờ, bạn có thể đưa ra lập luận rằng bạn có một nhánh "sạch" đại diện cho mã sẵn sàng sản xuất. Nhưng không sử dụng kiểm soát nguồn cho đến khi công cụ sẵn sàng là thẳng thắn tự đánh bại. Kiểu như cố gắng làm một ly martini mà không có rượu gin.


6
Hãy nhấn mạnh vấn đề phân nhánh và gắn thẻ. Đó là - tôi nghĩ - tính năng quan trọng khiến mọi người khăng khăng chỉ sản xuất trong SVN.
S.Lott

3
một điểm tuyệt vời, ngay cả với sự thiên vị của bạn chống lại vodka.
Covar

Khá nhiều? Tôi muốn nói ông sai chết. Không có câu hỏi về nó.
Steven Evers

2
@Covar: Tôi không làm ô nhiễm vodka của tôi với vermouth :)
Wyatt Barnett

22

"Tiền bối" thực sự rất không có kỹ năng. Bất kỳ mã nào có thể được biên dịch (và vượt qua các bài kiểm tra nếu bạn có chúng) nên được cam kết kiểm soát nguồn. Kiểm soát nguồn là tài sản trung tâm để chia sẻ mã và xây dựng SW tăng dần.

Điểm hay là tách mã sản xuất (phiên bản ổn định cuối cùng) nhưng đối với các hệ thống kiểm soát nguồn trường hợp như vậy có chứa các tính năng như thẻ / nhãn và chi nhánh.

Nhóm của chúng tôi rất nghi ngờ nếu ai đó không cam kết bất cứ điều gì trong vòng hai ba ngày. Nó có nghĩa là anh ta có một số vấn đề và có lẽ cần giúp đỡ. Một điểm khác của kiểm soát nguồn là nó thường được sao lưu thường xuyên, điều này không đúng với các máy phát triển. Nếu đĩa của bạn gặp sự cố, bạn sẽ mất việc trong vài tuần.


12
Nhưng anh ta không có kỹ năng làm việc như một thành viên trong nhóm.
Ladislav Mrnka

2
@Tom Hamming: Cắt mã không phát triển phần mềm. Tôi chắc rằng anh ta giỏi lập trình, nhưng ngày nay việc kiểm soát phiên bản không còn là "công cụ" nữa mà IDE là một công cụ. Chắc chắn, về mặt kỹ thuật bạn có thể làm mà không cần nó, nhưng không ai trong tâm trí của họ làm được.
Steven Evers

2
@SnOrfus - Mặc dù tôi đồng ý ở một mức độ nhất định về tiện ích của SCM, mục đích của tôi với câu hỏi này không phải là để đánh bại Joe và / hoặc các kỹ năng của anh ấy với tư cách là nhà phát triển. Một lần nữa, anh ấy tạo ra sản phẩm tuyệt vời, anh ấy có kiến ​​thức, và anh ấy đã làm tốt mà không cần SCM trong 10 năm qua. Mục tiêu của tôi với câu hỏi này là để xem liệu viễn cảnh của anh ta có phải là một quan điểm rộng rãi mà tôi đơn giản không gặp phải; Rốt cuộc, tôi mới ra trường và tương đối thiếu kinh nghiệm trong ngành này. Trong mọi trường hợp, tôi tin rằng anh ấy thực sự muốn đảm bảo chất lượng và độ tin cậy của quy trình làm việc.
Ông Jefferson

3
@Tom: Tôi có thể nói với bạn ngay bây giờ rằng bất kể bạn nghĩ gì về chất lượng công việc của mình, anh ấy không phải là nhà phát triển lành nghề nếu anh ấy không biết cách sử dụng kiểm soát nguồn đúng cách. Không có lựa chọn nào khác, ngoài việc có lẽ anh ta đang làm việc một mình trong tầng hầm. Ngay cả trong các dự án của riêng tôi, nơi tôi là nhà phát triển duy nhất, tôi vẫn sử dụng kiểm soát nguồn ở mức tối đa.
Jordan

5
@SnOrfus: Tôi có thể làm việc rất vui vẻ mà không cần IDE. Tôi sẽ không làm việc mà không có kiểm soát phiên bản. Nếu đội không sử dụng, tôi sẽ tự chạy.
kevin cline

12

Đặt sang một bên câu hỏi liệu Joe đúng hay sai (nhân tiện, anh ta đã sai), đối với tôi, dường như có thể đạt được thỏa hiệp nếu bạn sử dụng hệ thống kiểm soát phiên bản phân tán như Git hoặc Mercurial .

Bằng cách đó, bản thân bạn và nhà phát triển khác sẽ làm việc trên kho lưu trữ cục bộ của bạn, cam kết thay đổi kiểm soát nguồn sớm và thường xuyên, nhưng không đẩy các thay đổi của bạn sang kho lưu trữ "sản xuất" cho đến khi chúng được "kiểm tra và phê duyệt là sẵn sàng sản xuất". Bạn sẽ có một lịch sử đầy đủ về tất cả những gì bạn đã làm trong suốt nhiều tuần và Joe sẽ có một kho lưu trữ nguyên sơ chỉ có lịch sử thay đổi đã sẵn sàng để sản xuất.


1
Tôi đã nghĩ về điều này và thực hiện một chút điều tra (và nghe thấy những điều tốt), nhưng sự do dự của tôi nằm ở chỗ chúng tôi đã mua và cài đặt VisualSVN Server, và cả hai chúng tôi đều không có kinh nghiệm với Git hoặc Mercurial . Sẽ còn hơn cả một trận chiến khó khăn nếu tôi cố gắng thuyết phục mọi người chúng ta cần mua thêm phần mềm và / hoặc vứt bỏ một khoản đầu tư hiện có. Nhưng điểm tốt.
Ông Jefferson

3
@Tom: Nếu phải là Subversion ở mặt sau, bạn có thể sử dụng lớp tương tác Subversion của Git hoặc Mercurial cho những thứ không sẵn sàng sản xuất và đẩy công việc vào lật đổ khi nó sẵn sàng.
Ken Bloom

2
@Tom Hamming: Tôi chuyển từ SVN sang GIT gần một năm trước. Sau vài lần chửi thề ban đầu, tôi bắt đầu yêu thích nó (mặc dù dưới Cygwin, nó không hoạt động tốt như trong Linux). Tôi chưa bao giờ chi bất kỳ khoản tiền nào cho nó, tôi khá hài lòng với dòng lệnh và hai công cụ miễn phí đi kèm. Tôi thậm chí không làm việc để tích hợp nó vào IDE của mình (nhật thực). YMMV, nhưng nếu tôi ở vị trí của bạn, tôi sẽ sử dụng repo git riêng của mình và git svncho sự tương tác. Bạn không cần phải mua bất cứ thứ gì và bạn không cần phải thuyết phục bất cứ ai; họ thậm chí không cần biết.
maaartinus

1
@Tom Hamming: Là một nhà phát triển cá nhân, bạn có thể chọn thường xuyên git pushthay đổi của mình cho một số máy khác (làm bản sao lưu). Nó không phải là kho lưu trữ "chính".
Greg Hewgill

1
@Tom Hamming: Gắn bó với SVN vì bạn đã mua và cài đặt máy chủ SVN thực sự là một sai lầm chi phí chìm. Git và Mercurial đều miễn phí và chi phí VisualSVN đã được thanh toán, vì vậy hãy xem các tùy chọn của bạn như đi tiếp có mỗi chi phí thiết lập ban đầu (không) giống nhau.
Cercerilla

7

Nó không có ý nghĩa, vì những lý do rất bạn liệt kê. Nó giống như sử dụng kiểm soát phiên bản mà không có lợi ích của việc sử dụng kiểm soát phiên bản.


5

Tôi tin rằng Joe đã không hiểu rằng các hệ thống kiểm soát nguồn không phải là bản sao lưu vinh quang của các bản phát hành sản xuất mã nguồn, mà là một công cụ hữu ích cho các lập trình viên bằng cách đưa các từ vào các bước nhỏ hơn của tiến trình mã và trưởng thành cho bản thân và đồng nghiệp tương lai của bạn. Có lẽ Joe không quen làm việc trong các đội với mã người khác?

Đã bao giờ xem xét "tại sao dòng mã này được thêm vào"? Xác định vị trí cam kết đã giới thiệu nó, và xem nhận xét của nó. Nếu bạn chỉ cam kết khi đi vào sản xuất, các ý kiến ​​sẽ không đủ cụ thể để hữu ích cho bạn.

Tôi cũng đề nghị bạn nên sử dụng một công cụ mạnh hơn SVN. Bạn có thể thấy một giới thiệu tốt về các khả năng tại http://hginit.com/ của Joel Spoelsky.

Ông sử dụng đồng bóng, và có một số ứng cử viên những ngày này. Git được coi là rất mạnh mẽ và https://github.com/ có một số công cụ rất, rất hữu ích và cung cấp các tài khoản khởi động miễn phí để bạn có thể dùng thử thực tế.


3

Joe không giống như biết về SVN, hãy thử tìm hiểu về Chi nhánh, Thẻ và Thân ... Thẻ phù hợp với những gì Joe muốn. Một số đọc về thực hành tốt nhất của SVN sẽ không làm tổn thương


2

Không bao giờ sử dụng SVN vì vậy tôi không biết các thủ tục cho việc này sẽ là gì. Chúng tôi đang sử dụng ClearCase và thực tế ở đây là mỗi nhà phát triển có nhánh phát triển riêng, sau đó là nhánh tích hợp mà chúng tôi hợp nhất khi chúng tôi sẵn sàng bắt đầu thử nghiệm và một hoặc nhiều nhánh phát hành cho mã được tích hợp và thử nghiệm .


SVN cũng có thể làm điều đó.
Phil Lello

2

Joe là một hacker, không phải là một nhà phát triển. Anh ta có vẻ như là một hacker rất giỏi, nhưng anh ta đã sai về cách sử dụng kiểm soát sửa đổi. Vậy giờ làm gì với nó?

Dường như với tôi, tổ chức của bạn có một khoản đầu tư vào SVN và sẽ hạn chế sự nghiệp của bạn khi thách thức Joe và làm mất hiệu lực đầu tư đô la vào máy chủ SVN. Thiết lập repo GIT và sử dụng giao diện git svn để hoạt động theo cách bạn muốn (Đây là tất cả phần mềm miễn phí và sẽ mất một giờ đến một ngày để thiết lập, tất cả trên máy trạm của bạn). Xã hội hóa quy trình làm việc của bạn với Joe - anh ta có thể bảo vệ hệ thống niềm tin "không bị ô nhiễm SVN" của mình và duy trì uy tín của mình đối với con voi trắng đắt tiền trong góc (và bản ngã).

Trong một thời gian ngắn, tôi mong đợi Joe sẽ xem xét cách bạn làm việc và bắt đầu làm như vậy. Trong một hoặc hai năm, máy chủ SVN sẽ trở thành repo Git.


đầu tư đô la vào máy chủ svn sẽ không hơn đầu tư đô la vào máy chủ git repo ...
TZHX

2

Bạn có thể cố gắng thuyết phục Joe bằng những lý lẽ trên. Nếu điều này không thành công, hãy sử dụng SVN tại địa phương cho công việc phát triển của riêng bạn và hy vọng đôi khi nó sẽ được Joe chọn. Nếu bạn không thể thuyết phục họ bằng những lý lẽ, hãy làm điều bạn bị thuyết phục và cho họ thấy nó hoạt động. Loại phương pháp phân tán nhưng với các công cụ hiện có.


2

Tôi sẽ lặp lại @ Carson63000 ở đây và nói rằng tôi đã thấy thái độ này trước đây và nguyên nhân chủ yếu là do khả năng phân nhánh / sáp nhập khủng khiếp của VCS. Có một nhánh biên dịch và vượt qua các bài kiểm tra, với các thẻ cho mỗi bản phát hành, là một cách tiếp cận tuyệt vời nhưng không nên tuân theo điểm mà không có mã nào khác được cam kết. DVCS nói chung và git nói riêng, làm cho việc phân nhánh trở thành một hoạt động dễ dàng và phổ biến và nó làm giảm rất nhiều khó khăn với quy trình công việc này.


1

Lý do các hệ thống kiểm soát phiên bản thẻ hỗ trợ là vì bạn có thể gắn thẻ mã được chứng nhận và vẫn cam kết công việc hàng ngày của bạn. Bất cứ khi nào bạn có mã chất lượng sản xuất, bạn cam kết nó sẽ ghi một thẻ và bạn đã hoàn thành. Bạn biết điểm chính xác trong 'thời gian' bạn phải quay lại để có được những gì khách hàng có. Và bạn luôn có thể kiểm tra và so sánh các phiên bản mã khác nhau của mình. Bằng cách này, bạn có thể vừa hài lòng với những gì bạn có trong cơ sở dữ liệu kiểm soát nguồn. Nó hoạt động cho công ty tôi làm việc, có 100 nhà phát triển, tất cả đều làm việc trong cùng một dự án. Nó cũng sẽ làm việc cho bạn.


0

Điều khá phổ biến là chỉ lưu trữ mọi thứ trong các hệ thống kiểm soát phiên bản đã sẵn sàng để phân phối đến sản xuất. Đó là cách nó đã được thực hiện trong lịch sử trong nhiều thập kỷ, kể từ thời xa xưa khi việc lưu trữ đĩa tốn hàng trăm đô la cho mỗi megabyte và lưu trữ mọi thứ chỉ là quá đắt.

Nó không còn được coi là cách tốt nhất để làm mọi thứ, nhưng tôi hoàn toàn có thể hiểu tại sao mọi người vẫn làm điều đó, vì nhiều hệ thống kiểm soát phiên bản cũ vẫn đang sử dụng khiến bạn gặp khó khăn nếu không thể làm gì khác và vẫn giữ được kiến ​​thức về những gì của bạn mỗi bản phát hành là (hoặc đúng hơn, không có cách nào để biết bất kỳ bản phát hành nào mà không kiểm tra các thẻ trên mỗi tệp nếu bạn cần quay lại. Tôi đã thấy nhiều hơn một kho lưu trữ trong đó cách duy nhất để lấy lại một bản cũ phát hành là để lấy từ kho lưu trữ một tệp zip với mã nguồn và nhị phân cho bản phát hành đó).


Thật thú vị khi bạn cần lưu ý rằng các tệp nhị phân đã được bao gồm. Một cuộc thảo luận riêng mà chúng tôi có là có bao gồm các nhị phân được biên dịch trong kiểm soát nguồn hay không. Tôi nói không, vì nó lãng phí không gian và có nghĩa là bạn có thể làm bẩn thanh toán của mình chỉ bằng cách biên dịch. Tại sao các tập tin được biên soạn trong lịch sử bao gồm?
Ông Jefferson

các tệp nhị phân được đưa vào vì không thể phục hồi các nguồn phát hành một cách đáng tin cậy. Vì vậy, các tệp nhị phân được lưu trữ thay vào đó trong trường hợp cần thiết để khôi phục máy chủ về bản phát hành cũ hơn ... Thỏa hiệp dựa trên các quyết định tồi được đưa ra nhiều năm trước đó.
jwenting
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.