Quản lý kiểm soát phiên bản với máy chủ phát triển trung tâm (LAMP)


8

Tôi đang làm việc trong một nhóm nhỏ với tối đa 5 nhà phát triển (web). Bởi vì nhóm của chúng tôi đang phát triển thường xuyên và chúng tôi gặp vấn đề với nhiều người làm việc trên cùng một mã, chúng tôi đã quyết định thiết lập một VCS.

Tình hình hiện tại

Hiện tại chúng tôi đang làm việc với một máy chủ phát triển trung tâm (LAMP). Vì vậy, mọi nhà phát triển đều làm việc trên cùng một cơ sở mã và nếu mã được kiểm tra và sẵn sàng cho máy chủ trực tiếp của chúng tôi, chúng tôi chỉ cần sao chép nó qua ftp. Tôi biết đây là một số quy trình công việc anno 1600 nhưng vâng - đó là những gì nó cũng là lý do cho câu hỏi này.

Trên máy chủ phát triển, cấu trúc thư mục của chúng tôi trông như thế này:

/var/www 
      /Project1 
      /Project2 
      /Project3 
      ...

Ngoài ra, có một số ứng dụng không phải là ứng dụng web nhỏ - ứng dụng Android / iPhone / Windows 8, v.v. và một số công cụ C # cũng nên được đưa vào VCS.

Mục tiêu và vấn đề

Mục tiêu của chúng tôi là có được một thiết lập sạch cho một VCS, hoạt động cùng với một phần mềm theo dõi vấn đề, cho phép chúng tôi làm việc với cùng một dự án cùng một lúc mà không ghi đè mã của chúng tôi và chỉ đơn giản là cho chúng tôi lợi thế về kiểm soát phiên bản.

Tôi nghĩ rằng câu hỏi đầu tiên cho chúng ta là, chúng ta nên sử dụng công nghệ nào. Một số người trong chúng ta đã có kinh nghiệm lật đổ. Nhưng bởi vì git là một loại trở thành "tiêu chuẩn" và có rất nhiều đối số "pro git" trong số những người dùng web chúng ta có xu hướng sử dụng git.

Có sự bắt đầu không chắc chắn của chúng tôi. Để sử dụng git - một VCS phi tập trung - có vẻ như chúng ta phải bắt đầu sử dụng các máy chủ phát triển riêng biệt trên mỗi máy tính của nhà phát triển. Các vấn đề với đó là:

  • Đôi khi chúng tôi làm việc trên các máy tính khác nhau, vì vậy khi chúng tôi quên đẩy mã của mình, chúng tôi gặp sự cố.
  • Chúng tôi sẽ phải làm việc với các máy ảo vì các máy chủ dev phải giống như máy chủ trực tiếp của chúng tôi (Điều này đơn giản là không thể thực thi được trong môi trường của chúng tôi, tin tôi là không thể).
  • Máy chủ phát triển cũng thường phục vụ như một máy chủ "thử" hoặc "thuyết trình" trong đó những người không phải là nhà phát triển đã xem xét những gì đang diễn ra.

Có một thiết lập khả dĩ nào khác với git để chúng tôi có thể hưởng lợi từ hệ thống trong khi vẫn sử dụng một máy chủ phát triển (!) Không? Có thể với các thư mục khác nhau cho mỗi nhà phát triển. Hoặc chúng ta vẫn có thể làm việc trên cùng một cơ sở mã với việc có thể khóa các tệp mà chúng ta đang làm việc và sau đó cam kết chúng vào một kho lưu trữ. Có thể rất quan trọng để nói rằng mặc dù nó đã trở thành một yếu tố đối với chúng tôi nhưng vẫn không có gì lạ khi nhiều nhà phát triển làm việc trên cùng một phần của một ứng dụng cùng một lúc.

Câu trả lời:


6

Bạn đang đi đúng hướng, ở đây.

Có thể với các thư mục khác nhau cho mỗi nhà phát triển.

Vâng, chắc chắn các thư mục khác nhau cho mỗi nhà phát triển.

Máy bạn đang sử dụng là không thú vị. Chỉ cần đảm bảo rằng mỗi nhà phát triển đăng nhập như chính mình và kiểm tra một bản sao của git repo trong thư mục nhà riêng của mình. Bạn sẽ kết thúc với một vài bản sao của mã sống trong hệ thống tệp của mình, nhưng này, đĩa là miễn phí.

Đúng là git hỗ trợ hoạt động phi tập trung. Nhưng bạn sẽ không sử dụng nó theo cách đó trong quy trình làm việc điển hình của bạn. Chỉ cần đảm bảo rằng một repo trần có sẵn trên một số máy chủ thuận tiện và có tất cả mọi người lấy từ đó. Truy cập nó qua http, ssh hoặc thậm chí qua hệ thống tập tin nếu bạn muốn.

Bạn đã đề cập đến một khu vực "thử" như một phần của quy trình làm việc của bạn. Làm cho mình một việc. Thuê một nhà phát triển khác, tên là Jenkins, người cũng kiểm tra mã của bạn bằng git. Anh ấy đã thực hiện ở đây: http://jenkins-ci.org/ (và chạy theo http://tomcat.apache.org/doad-70.cgi ). Bằng cách đó, mỗi lần đẩy vào repo trung tâm sẽ ngay lập tức cung cấp phiên bản cập nhật của trang web của bạn trong thư mục chính của Jenkins, nơi bạn có thể nhanh chóng dùng thử và chạy kiểm tra độ tỉnh táo. Chúng tôi gọi đây là Tích hợp liên tục và chắc chắn nó sẽ cải thiện quy trình làm việc của bạn.


Tôi ước tôi có thể đưa ra một upvote bổ sung cho nhận xét về việc thuê Jenkins làm nhà phát triển bổ sung.
Bart van Ingen Schenau

5
 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

Nếu ít người làm việc trên cùng một máy và cùng một cơ sở mã hóa thì mọi thứ phải sai. Vì ghi đè và vì nếu một cái gì đó bị hỏng, người khác phải đợi cho đến khi sửa chữa để kiểm tra nội dung của họ.

Bạn cần phân biệt vài môi trường. Có vẻ như bạn cần ba (rất phổ biến):

  • Sản xuất - nơi dự án thực sự được sử dụng bởi người dùng cuối.
  • Dàn dựng - nơi mà nhà phát triển hợp nhất công việc của mình với các nhà phát triển khác, kiểm tra nó và đôi khi khách hàng có thể nhìn trộm vào khu vực này.
  • Phát triển - nơi mỗi nhà phát triển làm việc một mình, trước khi hợp nhất với những người khác.

Môi trường phát triển thông thường có nghĩa là nhà phát triển máy làm việc trên. Nếu bạn muốn giữ nó trên máy dùng chung, bạn cũng có thể làm điều đó. Môi trường và máy móc là một cái gì đó tách rời. Bạn chỉ cần có một cơ sở mã khác nhau cho từng dự án, từng nhà phát triển và từng môi trường.

Vì vậy, trong trường hợp Git và 5 nhà phát triển trong công ty, sẽ có 5 kho lưu trữ cho môi trường phát triển . Đối với môi trường dàn dựng (mã hợp nhất) bởi vì không nên chuyển sang các kho lưu trữ không trống, bạn sẽ cần một repo để hợp nhất và một mã khác để kiểm tra mã ở đó và hiển thị trạng thái hiện tại của máy khách. Nếu máy chủ sản xuất có Git khác ở đó. Nếu không, bạn sẽ chỉ chuyển tập tin sang sản xuất qua FTP từ môi trường dàn dựng . Vì vậy, rất ít kho lưu trữ cho mỗi dự án.

Và quy trình công việc là như vậy: Bạn làm việc trên môi trường phát triển của mình , khi bạn thêm một tính năng hoặc sửa lỗi, bạn sẽ thay đổi môi trường để dàn dựng repo trần và kéo nó ra ngoài không (một móc Git có thể làm điều đó ngay lập tức) và khi dự án sẵn sàng phát hành phiên bản mới, bạn đẩy (hoặc chuyển qua FTP) để sản xuất .

Đôi khi chúng tôi làm việc trên các máy tính khác nhau, vì vậy khi chúng tôi quên đẩy mã của mình, chúng tôi gặp sự cố.

Vâng, nếu bạn phải thực hiện môi trường phát triển trên cùng một máy chủ được chia sẻ, bạn có thể đồng bộ hóa các tệp của mình từ máy cục bộ sang máy chủ thông qua một cái gì đó như rsync, hoặc ánh xạ ổ đĩa mạng hoặc bất cứ điều gì nhưng điều này sẽ luôn chậm hơn một chút sau đó làm việc trên máy cục bộ . Làm việc tại địa phương tuy nhiên có vấn đề bạn đề cập. Ngay cả khi không có VCS. Giống như khi sử dụng FTP - nếu bạn thay đổi thứ gì đó trên máy và quên chuyển nó - điều tương tự cũng xảy ra. Nhưng bạn sẽ không muốn hợp nhất mã đã phân tách của mình vào môi trường dàn dựng . Nó phải ở trong sự phát triển cho đến khi đạt đến trạng thái có thể cộng hưởng.

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

Các máy chủ wev không có GUI không sử dụng nhiều tài nguyên. Tôi nghĩ rằng các bạn có thể làm việc với mã và kiểm tra tất cả mọi người trên máy của mình. Vì vậy, môi trường phát triển cục bộ, và chỉ dàn dựng trên máy chủ được chia sẻ. Bạn có thể kiểm tra một cái gì đó như Vagrant để giúp quản lý hình ảnh máy ảo. Vì vậy, bạn sẽ đảm bảo rằng mọi dự án đều có cài đặt đúng. Điều này sẽ đảm bảo rằng các bạn kiểm tra theo cách tương tự, an toàn hơn (bây giờ nếu máy chủ được chia sẻ sẽ không ai có thể tiếp tục làm việc và bạn cần có một bản sao lưu tốt ở đó) và nhanh hơn (không cần chuyển cho đến khi hợp nhất). Git tốt hơn mười SVN trong vấn đề này bởi vì nó giữ repo đầy đủ trên mỗi máy có lịch sử và mọi thứ vì vậy nếu một máy tính bị hỏng thì vẫn còn những bản sao tốt ở một nơi khác.

Ngoài ra, những thứ như Gitosis có thể giúp bạn quản lý cài đặt repo môi trường dàn dựng và Redmine hoặc phần mềm quản lý dự án khác thường có cách tích hợp với VCS.


1

bởi vì git là một loại trở thành "tiêu chuẩn" và có rất nhiều người "pro git" trong số những người dùng web chúng ta có xu hướng sử dụng git.

Đây là nền tảng kém để đưa ra lựa chọn trong thế giới SCM. Git không phải là "tiêu chuẩn", mà là "thời trang" với rất nhiều tiếng ồn xung quanh nó. "Pro Git" là sự cuồng tín, hơn là quyết định hợp lý và hợp lý trong rất nhiều trường hợp

làm việc togheter trên cùng một dự án cùng một lúc mà không ghi đè mã của chúng tôi và chỉ đơn giản là cung cấp cho chúng tôi lợi thế của kiểm soát phiên bản

Các chi nhánh trong bất kỳ SCM nào cũng sẽ cho phép bạn có được nó, ngay cả với Git (từ khóa: "Git-Flow")


Có thể cụm từ đầu tiên bạn trích dẫn là một chút sai hoặc mơ hồ. Tôi không quan tâm đến việc có bao nhiêu "người" là fanboy. Chỉ là nếu bạn tìm kiếm trên web những thứ như "git vs. svn" hoặc bất cứ thứ gì tương tự như vậy thì hầu hết các blogger / bình luận viên / người hỏi v.v ... đều là những người chuyên nghiệp và nghĩ rằng đó là SCM tốt hơn. Tôi sẽ không ngần ngại sử dụng một hệ thống khác nếu nó phù hợp hơn với mục đích của chúng tôi.
Marcel Gwerder

@MarcelGwerder - một hệ thống khác không tốt hơn cho mục đích của bạn (bất kỳ SCM nào có khả năng hợp nhất tốt sẽ làm bạn hài lòng và hợp nhất Git / theo nghĩa thông thường / tốt hơn so với svn), chúng có thể giúp bạn bớt đau đầu hơn và dễ học hơn, hơn Git . Tôi đã chạm vào Git, tôi sử dụng Subversion và Mercurial, không có lý do mạnh mẽ Tôi sẽ không bao giờ chọn Git làm SCM mà tôi chọn (SVN cho lịch sử tuyến tính và thay đổi đồng thời tối thiểu, Mercurial trong mọi trường hợp khó khăn hơn)
Lazy Badger

Hạ cấp. Trong năm 2013, DVCS thuộc loại nào đó hoàn toàn tiêu chuẩn và Git là DVCS phổ biến nhất.
Marnen Laibow-Koser
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.