Quy trình phát triển Web SVN

Question

Tôi đã đọc qua nhiều câu hỏi ở đây về SO liên quan đến vấn đề này, nhưng tôi thực sự không tìm được lời khuyên nào phù hợp với hoàn cảnh của chúng tôi. Tôi đã thừa hưởng luồng công việc này và tôi đang cố gắng làm cho nó tốt hơn.

thiết lập của chúng tôi

• mã PHP cơ sở (Kohana nói riêng)
• cơ sở mã quyền hạn ~ 60 trang web, mỗi mẫu duy nhất (tức là 60 QA [Quality Assurance] miền quá)
• mỗi trang web có hồ sơ A cho các tài sản và tài nguyên khác nhau (tức là 8 bản ghi A cho mỗi tên miền)
• 3 nhà phát triển
• 3 nhà thiết kế
• nhà phát triển có VMware hình ảnh của máy chủ sản xuất để phát triển địa phương
• nhà thiết kế không
• chia sẻ máy chủ phát triển thể chất dùng để bảo đảm chất lượng, một post-commit cập nhật giữ máy chủ này tại các HEAD hiện tại của thân cây bất cứ lúc nào
• sản xuất máy chủ, cập nhật để pha trộn và kết hợp các phiên bản khác nhau tùy thuộc vào những tính năng live

làm việc của chúng tôi chảy

• Nhà phát triển hoạt động cục bộ cho đến khi một tính năng nhất định hoàn tất và sau đó cam kết toàn bộ đối tượng địa lý vào thân cây cho QA nội bộ.
• Nhà thiết kế chỉ thực hiện các thay đổi nhỏ đối với CSS/hình ảnh/mẫu. Họ cam kết trực tiếp vào thân cây, QA thay đổi của riêng họ và cập nhật các tệp tương ứng trên máy chủ sản xuất, nói chung, ngay sau khi QA của họ.
• Khi các tính năng sẵn sàng phát trực tiếp, máy chủ sản xuất được cập nhật theo cách thủ công thành số sửa đổi thích hợp cho mỗi tệp có liên quan đến đối tượng địa lý. Đôi khi điều này là đơn giản, lần khác nó khá lông (rất nhiều các cuộc gọi svn log để tìm phụ thuộc ngược dòng).

vấn đề của chúng tôi

• Với ba nhà phát triển khác nhau làm việc trên các tính năng khác nhau mà cần số tiền khác nhau của QA, chúng ta thấy mình chạy vào các vấn đề phụ thuộc thượng nguồn một cách thường xuyên.
• Tại bất kỳ thời điểm nào, chúng tôi không có cách nào để xác định các tính năng nào có trên máy chủ sản xuất và không có tính năng nào. svn status -u sẽ hiển thị cho chúng tôi những tệp nào không được cập nhật, nhưng thường không phải là hình ảnh rõ ràng về các tính năng.

Những gì tôi biết

• Một số vấn đề của chúng tôi có thể khắc phục bằng việc có một chi nhánh sản xuất. Chúng tôi ít nhất có thể theo dõi các tính năng nào đang được thêm vào sản xuất và khi nào, mặc dù điều này sẽ không giải quyết được các vấn đề phụ thuộc ngược dòng.
• Chi nhánh tính năng là một tùy chọn và chúng tôi đã thử điều đó trong quá khứ.Do thực tế là phần mềm của chúng tôi yêu cầu 60 miền QA cho mỗi chi nhánh, chúng tôi gặp phải các vấn đề quản lý quy trình tại đó. Ví dụ, việc tạo ra 480 (60 tên miền x 8 bản ghi cho mỗi tên miền) Một bản ghi cho mỗi chi nhánh tính năng.
• Chi nhánh nhà phát triển cũng là một tùy chọn, nhưng thời gian QA tính năng của chúng tôi thay đổi. Tôi chắc chắn không thể nói rằng một tính năng trước đó sẽ hết QA trước khi tôi cần phải cam kết điều gì đó khác.

Upstream phụ thuộc Ví dụ

• Developer Một bổ sung thêm một tính năng slideshow mới trong cả admin và front-end.
• Nhà phát triển B thêm tính năng phản hồi mới trong cả quản trị viên và giao diện người dùng.
• Cả hai tính năng này được đan xen với logic Mô hình/bộ điều khiển vị trí, do đó, các thay đổi được thực hiện cho các tệp được liên kết đó để tính đến cả hai tính năng mới.
• Tính năng trình chiếu vào QA, nhưng được giữ lại bởi một số giám sát phát triển hoặc phạm vi leo.
• Tính năng phản hồi chuyển vào QA và chuyển mà không gặp vấn đề gì.
• Chúng tôi muốn theo dõi dòng thời gian và đẩy tính năng phản hồi vào sản xuất, nhưng chúng tôi không thể thực hiện trực tiếp vì cả hai tính năng đều yêu cầu thay đổi đối với mô hình/bộ điều khiển vị trí. Đó là, chúng tôi không thể chỉ làm một svn update file1 file2 file3.
• Lưu ý:Đây là một ví dụ đơn giản và có thể làm việc xung quanh bằng cách thực hiện một số hợp nhất ngược. Thông thường, các vấn đề của chúng ta phức tạp hơn điều này.

Multi-site Thông tin Cấu trúc

• Chúng tôi có một số chủ đề về cấu trúc được xác định trước, bao gồm các quan điểm, hình ảnh, file CSS, JS vv ​​
• Mỗi trang web được gán một chủ đề.
• Vì lý do xây dựng thương hiệu và khả năng mở rộng, mỗi trang web có thể ghi đè chế độ xem chủ đề bằng chế độ xem tùy chỉnh hoặc bao gồm các tệp CSS/JS bổ sung cho trang web bổ sung.

Tôi chắc chắn có một số người khác ở đó đã gặp khó khăn với các vấn đề tương tự và tôi hy vọng nhận được thông tin chi tiết từ những người thông minh trên Internet. Xin vui lòng đặt câu hỏi nếu một cái gì đó tôi nói có vẻ rõ ràng như bùn!

Answer 1

công việc của bạn có thể được cải thiện, đây là danh sách các lời khuyên của tôi:

• Bắt đầu sử dụng các chi nhánh SVN và phát hành xây dựng/triển khai trên một chu kỳ đều đặn.
• Tìm hiểu chu kỳ triển khai của bạn trong bao lâu, để lại thời gian cho QA. Vì vậy, ví dụ nếu bạn định phát hành một bản dựng mỗi tháng có 3 tuần phát triển và 1 tuần QA. Phát triển đóng băng cho bản dựng đó sau 3 tuần ngoại trừ các bản sửa lỗi.
• Quyết định lược đồ đánh số cho các bản dựng của bạn cho phép phòng phát triển
• Sử dụng hệ thống bán vé (ActiveCollab, JIRA, Mantis ... vv) và thực thi quy tắc đó. Chọn một nơi bạn có thể làm cho các cam kết của bạn hiển thị tự động trong vé.
• Nếu bạn định bắt đầu ghi lại yêu cầu của mình trước khi bắt đầu phát triển, đừng thu thập yêu cầu của bạn trong hệ thống bán vé (vì lợi ích của thần linh)
• Làm như vậy sẽ giúp bạn xác định những tính năng nào trong một bản dựng nhất định. Vì vậy, hãy tạo một số loại ghi chú phát hành với danh sách số vé hoặc mô tả chung về vé cho mỗi bản dựng.
• Nhúng số bản dựng vào ứng dụng của bạn để bạn có thể theo dõi việc triển khai trên bất kỳ hệ thống cụ thể nào.
• Bắt đầu làm việc với các công cụ kiểm thử tự động PHPUnit để kiểm tra đơn vị và Selenium cho các bài kiểm tra chức năng để tăng tốc độ QA và tăng chất lượng/tính ổn định của ứng dụng web bằng cách giảm khả năng thay đổi ngày này sang ngày khác.
• Hudson và Phing có thể là phao cứu sinh để tự động hóa các bản dựng của bạn và tự động hóa Thử nghiệm của bạn.

Answer 2

OK, một vài suy nghĩ:

Đối với loại công việc, bạn sẽ làm gì MUCH tốt hơn với một SCM với một mô hình dòng, giống như Accurev hoặc ClearCase. Trong mô hình luồng, luồng công việc từ mỗi luồng của nhà phát triển đến luồng tích hợp, sau đó đến luồng QA, sau đó phát hành luồng (hoặc bất kỳ luồng nào hoạt động tốt nhất). Chỉ có tác phẩm sẵn sàng để chuyển sang giai đoạn tiếp theo mới được chuyển lên và việc tích hợp có thể được thực hiện với các gói công việc đó một mình. Khi nói dối, bạn cần phải chia nhỏ nhiều thứ hơn theo kiểu mô-đun, nhưng bạn cũng cần phải kết hợp nó với một hệ thống bản địa hóa, nơi chức năng cụ thể của khách hàng có thể ghi đè các phần cụ thể của mã. Một cách tôi đã làm điều đó trong PHP là thực hiện một tệp trình bao bọc nhập tệp PHP, đầu tiên tìm kiếm một phiên bản máy khách cụ thể của tệp PHP và nếu nó không tồn tại, hãy tải một tệp chung chung.

function importModule($module, $clientId){ 
    if(is_file("${clientRootDir}/${clientId}/${module}.php")) { 
     import("${clientRootDir}/${clientId}/${module}.php"); 
    } else { 
     import("${defaultRootDir}/${module}.php"); 
    } 
} 

Sử dụng kỹ thuật đó, bạn duyên dáng có thể ghi đè lên các bộ phận của cách trang web làm việc cho chỉ khách hàng đó, và người làm việc trên chức năng cho khách hàng mà đang làm việc trong một tập tin hoàn toàn khác nhau vì vậy họ không đụng vào nhau. Tôi không chắc liệu bạn có đang thực hiện điều này hay không và đó là điều bạn gọi là "Mô hình vị trí"

Cuối cùng, với nhiều "trang web ảo" khác nhau để kiểm tra, bạn sẽ hưởng lợi vô cùng với việc thêm thử nghiệm đơn vị tự động (a la PHPUnit) kết hợp với tích hợp liên tục để tự động khởi động các thử nghiệm khi phần mềm hoạt động theo cách của nó lên đến giai đoạn tích hợp.