Lý tưởng cho môi trường phát triển/thử nghiệm/QA để phát triển

Question

Tôi đang làm việc để xây dựng lại môi trường dev/test/QA của công ty tôi. Chúng tôi có 10-15 lập trình viên tham gia vào một số dự án. Tất cả chúng đều phát triển cục bộ trên máy tính của họ và sử dụng môi trường dev để thử nghiệm. Hiện tại chúng tôi không có môi trường QA, vì vậy việc triển khai thường là một nỗi đau vì các lỗi thường được tìm thấy sau khi có sự cố. Đây là những gì tôi hình dung:

1. Làm đi với quyền quản trị cục bộ của mọi người và làm cho tất cả mọi người phát triển trên một máy chủ dev
2. Tạo một môi trường bảo đảm chất lượng giống hệt hệ thống sản xuất của chúng tôi. Điều này sẽ cho phép họ kiểm tra triển khai.
3. Tạo môi trường thử nghiệm mới bị khóa nhiều hơn máy chủ dev để có thể thực hiện kiểm tra thích hợp.

Suy nghĩ của bạn là gì? Cách tốt nhất để thiết lập một môi trường như thế này là gì? Chúng tôi phát triển các ứng dụng ASP .NET bằng cách sử dụng MS Visual Studio 2008 (nếu có ích).

Answer 1

Là nhà phát triển, tôi thực sự ghét nếu bạn đã khóa tôi khỏi đặc quyền quản trị viên cục bộ.

Tại sao mọi người phát triển trên máy chủ phát triển? Nhân viên của bạn không phải tất cả trong một môi trường văn phòng?

Điều duy nhất tôi thực sự thích về đề xuất của bạn là máy chủ QA giống hệt với môi trường sản xuất. Lấy làm tiếc.

Bạn nên:

• Quản lý mã thông qua kiểm soát mã nguồn
• Có một người quản lý xây dựng chuyên dụng đẩy xây dựng cho QA. Khi phê duyệt QA/đăng ký kinh doanh/chèn quy trình nghiệp vụ của bạn tại đây, thì người quản lý xây dựng sẽ đẩy mạnh sản xuất.
• Hy vọng bạn cũng có môi trường thử nghiệm cho cơ sở dữ liệu của mình. DBA nên quản lý việc đẩy các thay đổi cơ sở dữ liệu vào sản xuất. Các nhà phát triển tạo ra trên môi trường thử nghiệm, đó là một SQL Server/bất cứ điều gì trên một máy chủ khác mà tất cả mọi người sử dụng.
• Nếu bạn đang sử dụng sản phẩm MS - hãy cân nhắc tạo dự án của bạn WDP (Dự án triển khai web). MSBuild tích hợp với điều này, và bạn có thể bắn ra một build ngay từ một nhiệm vụ xây dựng TFS, ví dụ. Xây dựng gia tăng, xây dựng hàng ngày, hướng dẫn sử dụng chỉ - nó thực sự tốt đẹp khi bạn đã thiết lập nó một cách chính xác.

Answer 2

1. Không. Nó sẽ là một PITA và sẽ làm tổn thương năng suất của các nhà phát triển của bạn, bằng cách ảnh hưởng đến khả năng triển khai nhanh, gỡ lỗi mã của họ và chạy song song với nhiều phiên bản mã của họ.
   Tất nhiên, bạn nên buộc họ phát triển không phải là quản trị viên cục bộ, nhưng đó là một câu chuyện khác.
2. Có. Trong thực tế, tôi sẽ đi xa hơn và buộc tất cả mã đang được kiểm tra vào kho lưu trữ chính để thực hiện triển khai tự động trên một máy chủ sạch. Bạn cũng nên có một môi trường như vậy, nơi mã sẽ được đẩy vào sản xuất cũng được triển khai.
3. Có. Nó là một phần của mục 2.

Nhiệm vụ đầu tiên bạn muốn làm là đảm bảo tất cả các sản phẩm mà công ty của bạn hoạt động có gói triển khai ** mà bạn có thể triển khai một cách tự động máy móc**.Nếu bạn không có gói như vậy, bạn sẽ gặp rất nhiều rắc rối khi cố gắng ép buộc quá trình trên, vì mọi triển khai sẽ yêu cầu can thiệp thủ công, điều này sẽ tốn rất nhiều thời gian và nguồn lực mà không ai quan tâm.

Nhiệm vụ thứ hai là đưa ra cấu hình dứt khoát cho máy chủ triển khai của bạn và chuẩn bị hình ảnh, bất kỳ ai cũng có thể triển khai trên máy cục bộ hoặc máy ảo. Đây sẽ là đường cơ sở cho bất kỳ thử nghiệm nào của bạn và phải gần với cấu hình sản xuất thực tế nhất có thể.

Answer 3

Tôi không phải là người hâm mộ lớn của các nhà phát triển tập trung vào máy chủ dev. Folks sẽ có thể chỉnh sửa và hợp nhất từ ​​bất cứ nơi nào chúng xảy ra với bất kỳ hệ thống nào chúng xảy ra. Bạn đang cố giải quyết vấn đề gì với vấn đề này? Có thể có một giải pháp khác cho vấn đề đó.

Máy chủ QA là phải. Nhóm QA của bạn cần một nơi mà họ có thể đi để phá vỡ mọi thứ sẽ không ảnh hưởng đến phát triển.

Tôi giả định bởi máy chủ "TEST", đây thực sự là nơi xây dựng hàng đêm có thể được đặt để các nhà phát triển có thể thực hiện kiểm tra trước khi phát hành cho QA? Đó là một ý tưởng rất hay, và như Cen đề cập, hàng đêm xây dựng trên một nhiệm vụ xây dựng cho máy chủ đó có thể được sử dụng để giúp quá trình này cùng.

Answer 4

Điều này dường như đang la hét cho Continuous Integration đối với suy nghĩ của tôi. Đây là nơi bạn có phần thứ hai của môi trường dev không phải là máy cục bộ của ai đó nhưng có thể được sử dụng để hiển thị những gì hiện đang được thực hiện và đảm bảo việc hợp nhất mã không phá vỡ mọi thứ. Điều này tách biệt với môi trường thử nghiệm, đó là những gì mà QA sẽ sử dụng và môi trường bán sản phẩm khác là mức khác để nếu có hotfix để xuất bản, có thể được thực hiện riêng biệt hơn các bản phát hành lớn hơn. để QA thực hiện hồi quy đủ để đảm bảo chức năng mới không phá vỡ nhiều thứ.

Answer 5

Tôi sẽ không giải quyết vấn đề này bằng cách xóa đặc quyền quản trị cục bộ, điều này sẽ gây hại nhiều hơn lợi ích, nhưng tôi khuyên bạn nên thiết lập máy chủ xây dựng để xác minh các bản dựng trong môi trường được kiểm soát. Các công cụ tôi đã thông qua, mà tôi đã tìm thấy hoạt động rất tốt cho tôi và đội của tôi về một chục hay như vậy tình nguyện viên, là:

• JetBrains TeamCity - Tích hợp liên tục và xây dựng, cộng với đơn vị Á hậu kiểm tra
• Atlassian Jira - theo dõi vấn đề và quản lý dự án
• Atlassian Fisheye/Crucible - đánh giá mã và chỉ số mã chung.
• Máy chủ VisualSVN - kiểm soát mã nguồn
• VisualSVN Client (tích hợp với Visual Studio, cũng đáng giá).
• JetBrains ReSharper - năng suất lập trình và một số công cụ kiểm tra đơn vị gọn gàng.

Tôi không thể đề xuất các công cụ đó đủ cao. TeamCity giao dịch với "của bạn, chúng tôi tìm thấy lỗi sau khi chúng tôi xuất xưởng" bằng cách di chuyển các bản dựng của bạn khỏi các máy phát triển và xây dựng trong môi trường sạch sẽ, được kiểm soát. Nó cũng sẽ chạy các bài kiểm tra đơn vị và đảm bảo rằng bạn luôn có một bản xây dựng làm việc (bằng cách đặt tên và làm hỏng trình xây dựng).

Crucible là một sản phẩm có giá trị cho phép bạn đánh giá mã ngang hàng dễ dàng và với kiểm toán đầy đủ, vì vậy bạn có thể xác minh rằng chúng đang được thực hiện chính xác.

Các mục khác tôi nghĩ là tự giải thích, tất cả đều đóng góp vào 'thực hành tốt nhất' sẽ di chuyển cửa hàng của bạn một chặng đường dài lên 'Kiểm tra Joel'. Atlassian có một đề nghị cho 10 giấy phép với giá $ 10 đối với một số sản phẩm của họ, rất khó để đánh bại.

Mặc dù vậy, giải pháp cho các tai ương phát triển của bạn sẽ ít nhất là một phần văn hóa. Bạn có thể đặt những công cụ này (hoặc các công cụ khác) vào vị trí nhưng bạn sẽ cần mua từ nhóm và quản lý và bạn sẽ cần phải giải quyết các thực tiễn của mình để đảm bảo các nhà phát triển sử dụng chúng. Một số giáo dục lại có thể được riquired, bởi vì các nhà phát triển cẩu thả thường không thích bị buộc phải lên trò chơi của họ. Tôi sẽ bắt đầu với máy chủ xây dựng và nhấn mạnh rằng không có mã nào có thể được phát hành trừ khi nó đến từ một bản dựng tự động. Rất nhiều thực hành tốt sẽ rơi ra khỏi đó. Bạn có thể xem xét việc áp dụng thử nghiệm đơn vị và đánh giá mã như và khi nó phù hợp với tổ chức của bạn - nhưng có kế hoạch để làm điều đó ngay từ đầu.

Answer 6

Nếu bạn thực sự muốn sắp xếp mọi thứ, hãy xem khái niệm Triển khai liên tục, khái niệm này đang trở nên rất phổ biến. Đây là một số good introductory post; mục tiêu tổng thể là triển khai drect từ phát triển đến sản xuất, sử dụng kiểm tra tự động nghiêm ngặt để loại bỏ lỗi.

Thiết lập triển khai liên tục đầy đủ có thể hơi khó khăn khi tắt ban đầu, nhưng bạn có thể bắt đầu bằng cách thử quy trình này để phát triển từ phát triển sang QA.

Answer 7

Hãy nhớ rằng - không có điều gì là môi trường phát triển chung "lý tưởng" có thể được áp dụng trong mọi trường hợp. Thông thường, các hạn chế kỹ thuật ngăn cản việc áp dụng đầy đủ các ý tưởng này. Là một nhà thầu của một số năm nổi tiếng, tôi đã phát hiện ra rằng hệ thống tồi tệ nhất mà tôi làm việc không có quyền quản trị cục bộ, mọi cài đặt nhỏ đều yêu cầu được hỗ trợ kỹ thuật, và họ luôn nguyền rủa chúng tôi khi yêu cầu quá nhiều.

Kịch bản tốt nhất mà tôi có là: nếu bạn định xóa quyền quản trị cục bộ, hãy cung cấp cho họ máy ảo được lưu trữ cục bộ mạnh mẽ. Họ nên có một DMZ trên mạng để họ có thể làm bất cứ điều gì họ muốn với máy ảo. Nếu họ làm hỏng một thứ gì đó, bạn có thể khôi phục lại một máy ảo từ tập tin. Điều quan trọng với kịch bản này là sử dụng một kho lưu trữ nguồn tốt như GIT, Team Foundation Server, SVN, vv. Đây là cách phát triển được thực hiện - không phụ thuộc vào các máy trạm của nhà phát triển ngoài việc thực sự gõ mã .

Danh mục này và lời khuyên khác:

Cho phép các nhà phát triển toàn tự do trong máy ảo của họ (truy cập Internet, cài đặt ứng dụng, vv)

Sử dụng một kho kiểm soát nguồn tốt mà mỗi nhà phát triển có thể chi nhánh theo ý muốn từ. Thực thi kiểm tra liên tục (như một lần một giờ) và có một máy chủ xây dựng (tích hợp liên tục hoặc "CI") để kiểm tra các bản dựng bị hỏng. Máy chủ CI sẽ gửi email cho tất cả mọi người trong nhóm khi xây dựng bị hỏng.

Cung cấp cho mỗi máy địa phương những tài nguyên tốt nhất bạn có thể mua được. Tôi nghe lý luận này rằng 4GB là đủ cho Visual Studio. Không có gì là thêm từ sự thật. Bạn có thể quyết định gắn bó với điều này, nhưng hãy tin tưởng tôi - khi máy phát triển của bạn phân trang đĩa nhiều lần bởi vì mỗi lần xây dựng chiếm nhiều bộ nhớ, bạn sẽ mất vài phút mỗi giờ - mỗi tuần - trong năng suất bị mất vì máy chậm.

Cố gắng không nhìn xuống mũi của bạn tại nhà phát triển - họ sẽ ngửi thấy nó một dặm và gửi lại cho bạn (muốn chịu trách nhiệm cho các nhà phát triển không hài lòng khi xóa mã nguồn hoặc giới thiệu lỗi?). Có thể là lý do họ là "nhà phát triển cẩu thả" là bởi vì không ai khác trong công ty có thể quản lý mọi người. Các đội tốt nhất được dẫn dắt bởi các nhà quản lý dự án thông minh, cởi mở, có giáo dục. Họ có được những gì họ cần khi họ cần. Chi phí của phần mềm là NOTHING so với chi phí tiền lương của một nhà phát triển - nhưng tôi vẫn nghe về điều này hoặc người quản lý từ chối một sản phẩm bởi vì nó chi phí lớn. Lần trước nó là XML Spy - bởi vì "Notepad sẽ đủ". Chắc chắn nó sẽ - giống như chân đủ thay vì xe hơi, nhưng tôi không muốn đi bộ ở khắp mọi nơi chết tiệt!

Để chống lại các hạt - Tôi thực sự nghĩ rằng việc loại bỏ khả năng quản trị từ tất cả các nhà phát triển là một điều tốt NẾU bạn có thể tạo ra một poweruser với hầu hết các khả năng. Vấn đề lớn nhất tôi tìm thấy từ nhóm là những người áp dụng các bản vá lỗi hoặc cài đặt phần mềm bổ sung mà họ chưa xóa với quản lý. Lần trước ai đó cài đặt ReSharper và sau đó phàn nàn rằng máy đã di chuyển chậm. Họ có một máy 2GB và ReSharper 5 cần 4GB tối thiểu để chạy trên đầu trang của Visual Studio 2010.

Addtionally - học cách phát triển mà không cần sử dụng chuột. Đây là một khái niệm căn bản mà tôi biết nhưng con chuột chậm hơn các phím tắt. Trừ khi biểu tượng nằm ở góc của trang, phải mất trung bình một hoặc hai giây để tìm biểu tượng và nhấp. Ghi nhớ một phím tắt nhanh hơn.