Nhóm của bạn thực thi tiêu chuẩn nào cho việc triển khai mã phiên bản chính?

Question

Tôi rất tò mò về những loại tiêu chuẩn mà các đội khác đảm bảo được đặt ra trước khi các tàu mã (hoặc triển khai) ra khỏi cửa trong các phiên bản chính.

Tôi không tìm câu trả lời cụ thể cho từng câu hỏi, nhưng đây là ý tưởng về những gì tôi đang cố gắng để có ý tưởng.

• Đối với ứng dụng dựa trên máy chủ, bạn có đảm bảo việc giám sát được thực hiện không? Ở mức độ nào ... chỉ là nó phản ứng với ping, rằng nó có thể tấn công tất cả các phụ thuộc của nó tại bất kỳ thời điểm nào, rằng logic mà ứng dụng thực sự là dịch vụ (ví dụ: dịch vụ tính toán 2 + 2 thực sự trả về "4 ")
• Bạn có yêu cầu xây dựng tập lệnh tự động trước khi mã được phát hành không? Có nghĩa là, bất kỳ dev có thể đi bộ vào một hộp mới, yank một cái gì đó từ kiểm soát nguồn, và bắt đầu phát triển? Cho những thứ như một hệ điều hành và IDE, tất nhiên.
• Làm thế nào về tập lệnh triển khai tự động, cho các ứng dụng dựa trên máy chủ?
• Mức độ tài liệu nào bạn yêu cầu cho một dự án được "hoàn thành"?
• Bạn có đảm bảo rằng bạn có một kế hoạch dự phòng chính thức cho tất cả các thành phần chính của hệ thống, nếu nó dựa trên máy chủ không?
• Bạn có thực thi các tiêu chuẩn chất lượng mã không? Hãy suy nghĩ StyleCop cho .NET hoặc các đánh giá phức tạp về chu trình.
• Kiểm tra đơn vị? Kiểm tra tích hợp? Kiểm tra tải hiệu suất?
• Bạn có các tiêu chuẩn về cách ghi nhật ký lỗi của ứng dụng không? Làm thế nào về thông báo lỗi?

Một lần nữa, không nhất thiết phải tìm kiếm danh sách các câu trả lời theo từng dòng. Tóm lại, các mục không mã hóa nào phải phát hành mã đã hoàn thành trước khi được chính thức coi là "hoàn thành" cho nhóm của bạn?

Answer 1

Các minimun:

1. kiểm tra đơn vị làm việc
2. kiểm tra công việc tích hợp
3. triển khai trên sân khấu thử nghiệm ok
4. tay kiểm tra ngắn trên sân khấu thử nghiệm

tốt hơn:

1. kiểm tra đơn vị làm việc
2. checkstyle ok
3. kiểm tra công việc tích hợp
4. số liệu như jmeter và vùng phủ sóng thử nghiệm truyền
5. triển khai trên sân khấu thử nghiệm ok
6. một số xét nghiệm thủ công trên sân khấu thử nghiệm

cuối cùng triển khai trên giai đoạn sản xuất

Tất cả thử nghiệm đơn vị và tích hợp hoạt động tự động, tốt nhất trên máy chủ tích hợp liên tục như CruiseControl được thực hiện bởi ant hoặc maven. Khi phát triển các dịch vụ web, thử nghiệm với soapui hoạt động tốt.

Nếu sử dụng cơ sở dữ liệu, hãy nâng cấp tự động (ví dụ: liquibase) trước khi triển khai. Khi các dịch vụ bên ngoài được sử dụng, các kiểm tra cấu hình bổ sung là cần thiết, để đảm bảo các URL là ok (yêu cầu đầu từ ứng dụng, kết nối cơ sở dữ liệu, wsdl get, ...). Khi phát triển webpps, HTML validation trên một số trang sẽ hữu ích. Việc kiểm tra thủ công bố cục (ví dụ: sử dụng browsershots) sẽ hữu ích.

(Tất cả các liên kết ví dụ cho việc phát triển Java)

Và cuối cùng (nhưng không kém phần quan): tất cả đều được nghiệm thu vẫn đi qua? Sản phẩm có phải là chủ sở hữu muốn không? Thực hiện một đánh giá trực tiếp với anh ta trên hệ thống kiểm tra trước khi đi xa hơn!

Answer 2

Tôi chủ yếu phát triển web, vì vậy các mục của tôi có thể khác với của bạn. Chỉ cần ra khỏi đỉnh đầu của tôi ...

• Đảm bảo tất cả các dịch vụ web được up-to-date
• Đảm bảo tất cả cơ sở dữ liệu scripts/thay đổi/di cư này đã được triển khai đến máy chủ sản xuất
• Min tất cả js và các tệp css.
• Hãy chắc chắn rằng tất cả các đơn vị/chức năng/hội nhập/kiểm tra Selenium đang đi qua (Chúng tôi nhắm tới 95% + bảo hiểm thử nghiệm trong khi chúng tôi đang phát triển, vì vậy đây là những thường khá chính xác trong việc xác định một vấn đề)

Có nhiều , Tôi biết có, nhưng tôi không thể nghĩ ra bất cứ điều gì ngay bây giờ.

Answer 3

1. không có lỗi hiển thị? ok
2. thử nghiệm đơn vị hoạt động? ok (một số đã bỏ qua) ha well ok
3. thiết lập ya chắc chắn. ok
4. ghi nhật ký lỗi? tắt khóa học! :-) chúng tôi cần điều này! để sửa lỗi!
5. tất cả trên cruisecontrol.net đẹp.

Answer 4

Mỗi và mọi dự án đều khác nhau, tuy nhiên theo quy tắc chung, đây là những điều cốt lõi mà tôi đã cố gắng thực hiện trước khi cho phép mã đi ra ngoài tự nhiên.

Trong mọi thứ tự cụ thể:

1) xác định phiên bản ở nơi nó có thể được tìm thấy bởi một người dùng sau đó, điều này phải là duy nhất trong phiên bản này. (rất thường là "số phiên bản" được liên kết trên phân phối, thư viện và tệp thực thi hoặc người dùng có thể nhìn thấy từ hộp thoại "about". Có thể là số ở đăng ký nổi tiếng hoặc phần mềm bù đắp)

2) của mã chính xác được sử dụng để tạo bản phát hành.(nhãn hoặc một nhánh của bản phát hành trong hệ thống SCM là tốt cho việc này)

3) Tất cả các công cụ cần thiết để tạo lại nguồn phải được lưu ý và lưu trữ (nguồn từ bước 2 trở nên hạn chế sử dụng mà không cần)

4) Bản lưu trữ bản phát hành thực tế (bản sao của trình cài đặt chính xác được phát hành, người biết trong 7 năm công cụ của bạn có thể không có khả năng xây dựng nó, nhưng bây giờ ít nhất bạn có mã nguồn và có thể cài đặt ở bên cạnh bạn cho mục đích điều tra).

5) Tập hợp các thay đổi được ghi lại giữa phiên bản phát hành này và phiên bản trước đó là Ghi chú phát hành (Tôi thích sử dụng kiểu chắp thêm vào danh sách để tất cả các thay đổi phát hành có sẵn ở một nơi cho người dùng).

6) Hoàn thành chu kỳ kiểm tra phát hành ứng cử viên. Sử dụng tải và phân phối được tạo ra có thể phân phối bằng cách sử dụng kế hoạch kiểm tra đầy đủ/được kiểm tra để đảm bảo chức năng lõi hoạt động, tất cả các tính năng mới đều có mặt và hoạt động như dự định.

7) Theo dõi lỗi cho biết tất cả các mục chưa được đánh dấu được gắn cờ là a) cố định b) không phải là lỗi c) bị trì hoãn.

Bạn có thể rắc nhiều bước khác tùy thuộc vào tên miền hoặc kiểu phát triển, nhưng tôi sẽ nói rằng hầu hết phần mềm "nên" thực hiện các bước trên mỗi bản phát hành. YMMV.

Hãy vui vẻ xông vào lâu đài.

Answer 5

• Codestyle
• Các xét nghiệm tự động (tự động) (Unit- & Integrationtests)
• thử nghiệm bằng tay (bao gồm cả kiểm tra và beta giai đoạn)
• Whitebox công cụ kiểm tra thâm nhập công cụ kiểm tra thâm nhập
• Blackbox (tự động) (tự động)
• Theo dõi ngoại lệ/ghi nhật ký thủ công trên các giai đoạn thử nghiệm/beta trước khi triển khai
• khả năng để trở lại phiên bản trước đó bất cứ lúc nào
• đang xem xét & 'Việc đăng nhập bất hợp pháp'

Answer 6

Đối với web/ứng dụng nội bộ có một điều ngoài những đề nghị khác.

Đảm bảo liên quan đến nhóm triển khai/triển khai để bạn không phân phối phần mềm yêu cầu nhiều máy chủ hơn mà họ có (đừng cho rằng những người đang đẩy yêu cầu đã có).

Answer 7

• Xem lại danh sách kiểm tra: kiểm tra xem tất cả các tính năng mới, yêu cầu thay đổi và sửa lỗi đã lên kế hoạch cho phiên bản đã hoàn tất chưa.
• Xây dựng (trong máy xây dựng) biên dịch mà không có bất kỳ cảnh báo cũng như lỗi nào trong Chế độ phát hành.
• Tất cả các kiểm tra đơn vị tự động chạy mà không có lỗi.
• Tất cả tin nhắn và hình ảnh đã được nhóm sản phẩm chấp thuận.
• Kiểm tra hiệu suất không tệ hơn phiên bản cũ.
• Gói kiểm tra đầy đủ (thủ công) đã được nhóm kiểm tra kiểm tra mà không có lỗi.
  • Ứng dụng này được thử nghiệm trong nhiều trường hợp có thể xảy ra (hệ điều hành khác nhau, công cụ cơ sở dữ liệu, cấu hình và ứng dụng của bên thứ ba).
  • Tất cả các tính năng của ứng dụng được kiểm tra: nhiều lần xảy ra với chúng tôi rằng thay đổi tính năng đã phá vỡ một ý tưởng khác không liên quan, shit xảy ra, vì vậy chúng tôi phải giảm thiểu nó.
  • Quá trình cài đặt hoặc triển khai hoạt động ở tất cả các kịch bản quá
  • Cách cài đặt có thể nâng cấp lên phiên bản cũ

Answer 8

Chúng tôi đã làm một phiên bản lớn thời gian gần đây, vì vậy đây là vẫn còn khá mới mẻ trong tâm trí tôi. Chúng tôi tạo một ứng dụng Windows với GUI mà chúng tôi phát hành tệp nhị phân có thể thực thi được, vì vậy danh sách của tôi nhất thiết sẽ khác với bản phát hành chỉ dành cho web.

1. Ứng viên phát hành sẽ tham gia nhóm thử nghiệm. Họ cần ít nhất vài ngày để chơi với nó. Nếu họ tìm thấy bất kỳ lỗi nào mà chúng tôi coi là hiển thị các nút, bản phát hành bị hủy bỏ. Điều này giả định bạn có một nhóm thử nghiệm. Chúng tôi chỉ xóa một ứng cử viên phát hành nếu ít nhất một tuần đã trôi qua kể từ ngày xây dựng.

2. Tất cả thử nghiệm tự động đều phải hoạt động và vượt qua. Thử nghiệm tự động được coi là bổ sung cho người thử nghiệm trực tiếp.

3. Bất kỳ lỗi nào được đánh dấu là "trình chặn" phải được giải quyết cho bản dựng cuối cùng.

4. Tài liệu công khai phải sẵn sàng (trong trường hợp của chúng tôi, bản cập nhật trang web và bản tin email). Người bán lại được cảnh báo rằng bản phát hành sẽ đến trước vài tuần để họ có thể chuẩn bị tài liệu của họ. Điều này chủ yếu không phải là một mối quan tâm lập trình, nhưng chúng tôi kiểm tra tính chính xác của tiếp thị.

5. Cấp phép phải được cập nhật để phản ánh bất kỳ bản sao bảo vệ nào chúng tôi đang sử dụng. Phiên bản beta của chúng tôi và các phiên bản phát hành sử dụng các mô hình cấp phép khác nhau và thay đổi này yêu cầu nỗ lực lập trình.

6. Thỏa thuận cài đặt và giấy phép phải được cập nhật. Kể từ khi các phiên bản beta có một trình cài đặt, điều này thường chỉ là một thay đổi văn bản, nhưng nó vẫn rơi vào các lập trình viên để thực sự cập nhật kịch bản cài đặt.

7. Mọi tham chiếu đến phiên bản beta cần phải được xóa khỏi chính ứng dụng. Chúng tôi đã bỏ lỡ một vài trong số này, xấu hổ.

8. Tệp trợ giúp và hướng dẫn sử dụng phải được cập nhật hoàn toàn và được hiệu đính, vì chúng là một phần của gói phát hành.

9. Nếu có lỗi không thể sửa được kịp thời, ít nhất chúng ta sẽ cố gắng giảm thiểu thiệt hại - ví dụ, phát hiện ra lỗi như vậy đã xảy ra và hủy bỏ thao tác với một lời xin lỗi thông báo lỗi. Điều này góp phần rất lớn vào sự ổn định của sản phẩm.

Xa và xa, những khó khăn của bản phát hành chính không phải là vấn đề lập trình, chúng là vấn đề về quản trị/tiếp thị. Nhiều thứ trong số này đòi hỏi sự chú ý của lập trình viên - giúp người cài đặt, đọc bằng chứng danh sách tính năng để đảm bảo rằng không có gì là vô nghĩa, các phần kỹ thuật đọc bằng chứng của hướng dẫn, cập nhật cấp phép, v.v.Sự khác biệt chính về kỹ thuật là sự thay đổi từ sửa lỗi để giảm thiểu lỗi.