Bạn có thể làm gì để giảm số lượng lỗi triển khai của một trang web trực tiếp?


11

Tôi chắc rằng rất nhiều bạn đã trải qua vấn đề này. Một trang web hoặc ứng dụng web đang chạy và đang hoạt động. Bạn muốn tải lên phiên bản tiếp theo, nhưng bạn chưa tìm ra mọi thứ, như đặt giá trị thành false trong tệp cấu hình, chèn một bản ghi khác vào cơ sở dữ liệu và thực hiện nhiều nội dung nhỏ đôi khi có thể đếm đến 20 hoặc nhiều tham số.

Ngay khi bạn tải lên phiên bản mới, mọi thứ sẽ vỡ. Bây giờ, việc khắc phục sự cố có thể chỉ mất tối đa 20 phút, nhưng sự căng thẳng chung mà bạn chịu đựng và thiệt hại về tài chính và thiện chí đối với công ty đôi khi không thể quên được.

Các cách để giảm các loại lỗi phát sinh từ cấu hình ban đầu của việc triển khai phiên bản mới là gì?

PS: Vui lòng không đề cập đến danh sách kiểm tra, vì chúng tôi đã có chúng. Vấn đề với danh sách kiểm tra là, chúng sẽ luôn được cập nhật, nhưng chúng sẽ không được cập nhật.


6
Bạn không nên phá vỡ trang web của bạn khi bạn cập nhật nó. Nếu bạn là ... thì thủ tục của bạn là sai.
Ramhound

10
"Vấn đề với danh sách kiểm tra là, chúng sẽ luôn được cập nhật, nhưng chúng sẽ không" Trong trường hợp đó, bạn sẽ phải chịu số phận. Chúng tôi có thể cho bạn biết những điều tốt để làm và - giống như danh sách kiểm tra - nó sẽ không được thực hiện. Nếu bạn không thể cập nhật danh sách kiểm tra, bạn nên xem xét việc tìm một loại công việc khác là lỗi và sự chậm chạp được dung thứ tốt hơn. Có lẽ dịch vụ của chính phủ.
S.Lott

5
Nếu bạn chưa tìm ra mọi thứ, bạn không nên triển khai.
HLGEM

Nếu việc triển khai thất bại, bạn phải khôi phục lại.
Tulains Córdova

Câu trả lời:


28

Hai điều:

  • Môi trường dàn dựng, tương tự như môi trường sống nơi bạn thực hiện các triển khai thử nghiệm.
  • Thử nghiệm rộng rãi của môi trường này sau khi triển khai. Tự động và không tự động.

Có những thứ khác có thể được thực hiện.

Tôi đề nghị đọc loạt blog gồm 5 phần về triển khai tự động của Troy Hunt. Các công cụ anh sử dụng là MS stack cụ thể, nhưng các khái niệm là phổ quát.


bạn có nghĩa là tất cả các trang web trên toàn thế giới có một môi trường dàn dựng .
Saeed Neamati

15
Không phải tất cả trong số họ. Đó là lý do tại sao họ có vấn đề như vậy với việc triển khai. Bất kỳ trang web có kích thước đáng kể mà tôi đã làm việc với đều có một.
Oded

@Saeed Neamati - Tất nhiên không phải đây là lý do chính xác nên nhiều trang web không thực sự hoạt động như họ nên (tức là trang web tín dụng của tôi liên kết trang web thanh toán tải bên ngoài) khi khách hàng của bạn trong lĩnh vực chỉ cười nhạo bạn. Trong trường hợp của tôi, tôi có sự lựa chọn nhưng sử dụng trang web công đoàn tín dụng của mình.
Ramhound

6
@saeed: Tôi không thể nói cho thế giới nhưng tất cả tôi chắc chắn làm được.
Wyatt Barnett

1
@saeed tất cả những người tốt làm.
HLGEM

13

Tôi tự hỏi, tại sao không ai đề cập đến Kiểm soát phiên bản - đó là một trong những cách quan trọng nhất để cứu bạn khỏi rắc rối trong khi cập nhật / nâng cấp.

Đầu tiên, việc triển khai của bạn chỉ là một bản sao của nhánh ổn định trên kho lưu trữ của bạn. Tất cả mọi thứ bao gồm tệp cấu hình, tệp SQL, tập lệnh cài đặt / cập nhật PHẢI được kiểm soát phiên bản.

Thứ hai, bạn cần có khu vực tổ chức "một số loại" - đó có thể là bất cứ thứ gì - một máy chủ cục bộ, một máy chủ đám mây ảo tạm thời bạn vừa sinh ra, một thiết lập máy chủ ảo rất đơn giản hoặc một ứng dụng tùy chỉnh hoàn chỉnh bạn duy trì cùng với ứng dụng chính. Sự khác biệt giữa "khu vực tổ chức" này và "khu vực phát triển" của bạn là các mô hình trước đây (hoặc mô phỏng) môi trường triển khai thực tế của bạn. Ví dụ: bạn có thể phát triển trên PHP 5.3.x với mô-đun Apache, nhưng vì máy chủ của bạn là PHP 5.2.x với FCGI, khu vực tổ chức của bạn phải giống nhau.

Sau đó, trước tiên bạn viết và kiểm tra cập nhật của bạn trên môi trường phát triển của bạn. Hợp nhất những thay đổi đó với kho lưu trữ khu vực tổ chức và kiểm tra lại. Tại thời điểm này, bạn có thể thực hiện bất kỳ thay đổi nào đối với cấu hình của mình để phù hợp với việc triển khai của mình - vì phiên bản được kiểm soát, sẽ không có gì bị mất và bạn luôn có thể quay lại trong trường hợp có vấn đề.

Cuối cùng, hợp nhất các thay đổi khu vực tổ chức trên bản sao triển khai trực tiếp của bạn.

Sự phức tạp của khu vực tổ chức của bạn sẽ phản ánh mức độ phức tạp và phạm vi của ứng dụng của bạn. Nhưng trong mọi trường hợp, kiểm soát phiên bản là không thể thiếu.

Tất nhiên nếu bạn không sử dụng Kiểm soát phiên bản - không áp dụng điều này - nhưng sau đó, nó ngây thơ như viết cơ sở dữ liệu trong Logo.


3
+1 nhưng tôi đã không đề cập đến nó bởi vì tôi chỉ hiểu rằng kiểm soát phiên bản đã được hiểu ...
maple_shaft

3
Vâng, thật đáng ngạc nhiên khi nhiều người chỉ kiểm soát mã mà họ quan tâm chứ không phải những thứ như cấu hình, SQl, v.v.
HLGEM

1
@HLGEM, Bạn đúng là đáng buồn, tôi kiểm soát mọi thứ, tôi thậm chí có một máy chủ lật đổ đang chạy ở nhà cho các tài liệu KHÔNG PHÁT TRIỂN tôi có ở nhà như sơ yếu lý lịch và công thức nấu ăn của tôi. :)
maple_shaft

2
@maple_shaft, Ohhhh, tôi chưa bao giờ nghĩ phiên bản kiểm soát hồ sơ của tôi, thật là một ý tưởng tuyệt vời.
HLGEM

3
Chắc chắn là một ý tưởng tuyệt vời - một ngày nào đó bạn sẽ nhìn vào nhật ký và xem những gì bạn đã học và làm thế nào bạn trở nên ngày càng có kinh nghiệm hơn khi thời gian trôi qua. Và, nếu bạn cam kết một hoặc hai tháng một lần, nhật ký của bạn sau 25 năm sẽ rất thú vị.
treecoder

6

Theo đề xuất, sử dụng một hệ thống dàn . Điều này cho bạn cơ hội để kiểm tra những thay đổi của bạn trong môi trường sống.

Điều này mang đến một điểm khác: có người kiểm tra . Kiểm tra những thứ tôi tự viết không tìm thấy nhiều lỗi như khi người khác kiểm tra ứng dụng của tôi.

Một điều nữa: tự động hóa quá trình triển khai của bạn . Thực hiện di chuyển db với ant di chuyển, tự động triển khai phiên bản mới nhất từ ​​svn qua capistrano, v.v. Khi bạn triển khai một cái gì đó, bạn không cần phải làm nhiều hơn chỉ cần một cú nhấp chuột và mọi thứ đều tự động. Đặc biệt đối với các trang web cần một số thiết lập cấu hình, các bước thủ công cần thiết để triển khai là một cơn ác mộng và khả năng xảy ra sự cố rất lớn.


6

Đối với một cái gì đó tuyệt đối, tích cực không được phá vỡ xem xét có hệ thống A và B và sử dụng bộ cân bằng tải để định tuyến tất cả các yêu cầu đến A trong khi bạn nâng cấp và kiểm tra B, sau đó định tuyến mọi thứ đến B trong khi bạn cập nhật A.

Để có điểm thưởng, hãy thêm C và đảm bảo các hệ thống của bạn được phân tách theo địa lý để một trận động đất sẽ không loại bỏ được 2 trong số chúng.

Đối với nhiều ứng dụng, tôi thừa nhận rằng điều này là quá mức cần thiết.

Nó cũng làm phức tạp bất kỳ quản lý giao dịch nào bạn cần làm, nhưng các vấn đề không phải là không thể vượt qua.


1
Đây là câu trả lời đúng

2
Cảm ơn bạn. Nhưng phiên bản, hệ thống dàn và triển khai một chạm cũng rất cần thiết.
Bill Michell

5

Có, bạn cần một môi trường thử nghiệm hoặc dàn dựng nơi bạn trải qua tất cả các bước, nhưng việc giữ các tệp cấu hình riêng biệt cho các môi trường riêng biệt là điều bắt buộc.

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

Về cơ bản trong các tập lệnh xây dựng và triển khai của tôi, tôi lấy một thuộc tính môi trường sẽ tìm nạp các tệp dữ liệu meta cụ thể của môi trường như các tệp XML và thay thế chúng trong vị trí xây dựng của tôi trước khi đóng gói. Hơn nữa trong các kịch bản triển khai của tôi, tôi sẽ tìm kiếm bất kỳ tệp SQL nào trong các bản cập nhật cơ sở dữ liệu và thực hiện các tệp trên cơ sở dữ liệu được cấu hình cho môi trường đó.

Tôi có thể làm điều này với một nhiệm vụ xây dựng tùy chỉnh, nhưng tôi thực sự chỉ sử dụng một số thử nghiệm JUnit để làm điều này cho tôi. Nếu bất kỳ trường hợp ngoại lệ SQL nào xảy ra thì thử nghiệm thất bại và do đó việc triển khai thất bại. Nói chung, các tập lệnh SQL cũng có trí thông minh, nếu dữ liệu cần thiết đã tồn tại trong môi trường thì chúng bỏ qua phần chèn hoặc cập nhật.

Tôi cũng có một thư mục tương tự cho các tập lệnh shell hoặc shell mà tôi cần để chạy cho một môi trường cụ thể.

Điều cần nói với tất cả trong câu hỏi của bạn là: chúng sẽ luôn được cập nhật, nhưng chúng sẽ không được cập nhật.

Các cấu hình này thúc đẩy các bản dựng và triển khai tự động của bạn, vì vậy nếu bạn không cập nhật chúng thì các bản dựng của bạn không thành công và người quản lý của bạn sẽ được gửi email về nó. Sau đó, điều quan trọng là nhóm phải duy trì cấu hình xây dựng và triển khai cho một bản phát hành cụ thể vì đó là để họ kiểm tra mã biên dịch. Hoặc là vi phạm phá vỡ các bản dựng.

Nói tóm lại, việc áp dụng nhiều hơn các nguyên tắc tích hợp liên tục (CI) sẽ giúp loại bỏ nỗi đau của các bản phát hành sản xuất.


4

1) Triển khai đến trang web thử nghiệm trước và kiểm tra các thay đổi của bạn

2) Có tất cả cấu hình trong một tệp cấu hình (cấu hình web hoặc tương tự). Cấu hình này sau đó phải dành riêng cho ứng dụng và không bao giờ bị ghi đè. Bất kỳ thay đổi nào sau đó sẽ được hiệu chỉnh thay vì quên thay đổi một cái gì đó khác với thử nghiệm.


Và đảm bảo có ai đó xem lại mã cấu hình đó cho từng môi trường khác nhau.
HLGEM

4

Ngoài các đề xuất tuyệt vời ở trên để có môi trường tiền sản xuất và sử dụng thử nghiệm tự động:

Giảm độ phức tạp của codebase. Ít mã hơn, nói chung, có nghĩa là ít lỗi hơn và thời gian dễ dàng tìm thấy chúng hơn. Đây là triết lý đằng sau tái cấu trúc, tách các mối quan tâm, v.v.

Phân đoạn cơ sở mã . Một cách tiếp cận phổ biến là tách nó thành:

  • một vài phần cốt lõi thay đổi chậm và được chia sẻ trên trang web
  • nhiều phần lá có thể thay đổi nhanh hơn nhưng mỗi phần chỉ tác động đến một phần nhỏ hơn của trang web

Sự hiểu biết về cơ sở mã của bạn cho phép bạn tập trung phát triển và thử nghiệm vào các phần cốt lõi, vì các lỗi sẽ có tác động mạnh mẽ nhất.


3

Một bản phát hành được thực hiện tốt là tất cả về kế hoạch và truyền thông. Vì vậy, trước khi tiến hành phát hành, hãy xem xét các câu hỏi sau:

  1. Việc phát hành có thể mất bao lâu và có rủi ro nào trong việc cho phép mọi người tiếp tục giao diện với sản phẩm của tôi trong khi quá trình phát hành đang diễn ra không? Nếu có rủi ro cho hệ thống, hãy xem xét đưa hệ thống ngoại tuyến và đưa ra thông báo "Hệ thống hiện đang bảo trì".

  2. Có khách hàng nào bạn có thể cần thông báo về việc phát hành trước thời hạn không? Tôi có cần nói với họ về sự gián đoạn dịch vụ có thể xảy ra hoặc sự suy giảm hiệu suất trong khi quá trình phát hành đang diễn ra không? Cá nhân tôi luôn nhầm lẫn về việc giao tiếp quá mức và nói với tất cả khách hàng về một cửa sổ phát hành hoặc bảo trì sắp tới trên một blog công khai hoặc một địa điểm tương tự.

  3. Kế hoạch dự phòng của tôi nên phát hành là gì? Ví dụ: nếu bản phát hành không tốt, chúng ta có nên khôi phục và khôi phục hệ thống theo cách để giảm thiểu bất kỳ lúc nào chúng ta ngoại tuyến không? Và nếu vậy, các bước để quay lại một bản phát hành có được ghi chép lại không? Hoặc tôi nên có đúng người trong cuộc gọi hoặc có mặt để hỗ trợ khắc phục sự cố nếu chúng xảy ra. Cá nhân, tôi nghĩ cách tốt nhất để tiếp cận việc lập kế hoạch cho bất kỳ bản phát hành nào là giả định rằng có điều gì đó không ổn với bản phát hành. Bằng cách đó, tôi đã buộc bản thân phải suy nghĩ về một số vấn đề này trước thời hạn.

Tiếp theo, khi thực hiện một bản phát hành, một trong những cách tốt nhất để đảm bảo rằng nó sẽ chạy trơn tru là luyện tập, luyện tập, luyện tập và ghi lại mọi thứ bạn gặp trên đường đi. Vì vậy, trước khi triển khai mã mới vào sản xuất, trước tiên hãy thực hành triển khai mã đến một môi trường dàn dựng an toàn, được đóng hộp cát đúng cách. Có người sẽ chịu trách nhiệm triển khai sản xuất, thực hiện triển khai thử nghiệm để dàn dựng. Hãy xem xét việc này trang phục của bạn và tiến hành như bạn sẽ làm nếu đây là thực tế. Tài liệu mọi thứ bạn làm mỗi bước trên đường đi; ghi lại mọi lệnh bạn thực thi, bất kỳ mã SQL nào bạn chạy, bất kỳ tệp nào bạn sửa đổi và cách bạn sửa đổi chúng và cho từng bước trên đường dẫn tài liệu bạn muốn xem liệu quy trình có được thực hiện đúng không. Nếu và khi bạn gặp phải một vấn đề nào đó, hãy ghi lại những gì bạn đã làm để giải quyết nó.

Sau đó, việc triển khai thực hành hoàn tất, xem qua các ghi chú của bạn và xem liệu bạn có thể tinh chỉnh quy trình để loại bỏ lỗi không. Sau đó làm lại tất cả . Tiếp tục thực hành cho đến khi thực hiện một bản phát hành trở thành thói quen như sau một bảng hướng dẫn đơn giản, như "đăng nhập vào máy này, thực thi lệnh này, sau đó đăng nhập vào cơ sở dữ liệu và thực hiện lệnh SQL này; sau đó ..."

Được liệt kê ở trên là những điều mà một nhóm hoạt động hoặc nhóm quản lý phát hành có thể làm để giúp bản phát hành chạy trơn tru. Nhưng kỹ thuật có thể làm gì để giúp giảm thiểu rủi ro trong một bản phát hành?

  1. Giữ bản phát hành nhỏ. Nói một cách đơn giản, tập hợp các thay đổi mã được phát hành trong một bản phát hành càng phức tạp thì việc phát hành sẽ càng trở nên rủi ro hơn. Làm cho nhóm hoạt động của bạn có lợi cho mình bằng cách lập kế hoạch để có số lượng phát hành nhỏ lớn hơn, thay vì số lượng phát hành lớn hơn trong cùng khoảng thời gian.

  2. Kiểm tra, kiểm tra, kiểm tra. Đừng chỉ kiểm tra mã của bạn trong môi trường QA của bạn, hãy sử dụng môi trường dàn để kiểm tra phần mềm của bạn. Thường có những lỗi có ít hoặc không liên quan gì đến bản thân mã, nhưng có một nguyên nhân gốc rễ nằm ở cấu hình của chính môi trường (hoặc một số kết hợp của cả hai). Để tìm ra những vấn đề này, bạn cần kiểm tra mã của mình trong một môi trường phản ánh chặt chẽ việc sản xuất, còn gọi là dàn dựng.

Như một lời cuối cùng, đôi khi điều quan trọng nhất không phải là những gì chúng ta làm để ngăn chặn những điều sai trái, mà đó là cách chúng ta tự hành xử khi họ làm sai. Do đó, tôi nghĩ điều quan trọng là xây dựng văn hóa trong công ty của bạn xung quanh tính minh bạch trong hoạt động. Đừng cố gắng che giấu các vấn đề từ khách hàng, sắp tới. Sử dụng Twitter một cách tích cực để cho khách hàng biết nếu có vấn đề mà nhóm op của bạn hiện đang biết và đang giải quyết ( Ngọn hải đăng thật tuyệt vời ở đây!). Xem xét xuất bản trang "trạng thái" cho dịch vụ của bạn mà khách hàng có thể tham khảo để xem có gì sai không ( TypePad cung cấp một ví dụ tuyệt vời về điều này). Điểm mấu chốt, luôn luôn lỗi về phía giao tiếp quá mức. Khách hàng của bạn sẽ cảm ơn bạn vì điều đó.


1

Nhiều câu trả lời ở đây đã cho bạn biết cách triển khai giải pháp cụ thể cho vấn đề của mình, nhưng, theo như tôi có thể nói, vấn đề thực sự không phải là vấn đề di chuyển / cập nhật trang web đúng cách. Nó có thể là thiết kế / kiến ​​trúc đằng sau nó là mong manh.

Nếu đó là sự thật, bạn sẽ phải điều chỉnh kiến ​​trúc cho hệ thống của mình sao cho nó đủ mạnh để tiếp tục hoạt động đúng ngay cả khi cài đặt cấu hình thay đổi hoặc không được đặt đúng, và nó sẽ xuống cấp một cách duyên dáng nếu chúng xảy ra. Lý tưởng nhất là nếu bạn đã thêm chức năng mới hoặc thay đổi chức năng cũ theo cách yêu cầu cột cơ sở dữ liệu mới, trang web của bạn sẽ hoạt động ngay cả khi cột bị thiếu (có thể không có chức năng mới hoặc với hình thức xuống cấp của chức năng cũ) . Khách hàng của bạn không nên mất tiền - tệ nhất, anh ta có thể không nhận được tiền mới từ những cải tiến bạn đã đưa vào.

Nếu hệ thống của bạn đủ mỏng để các cài đặt cấu hình có thể gây ra sự cố nghiêm trọng như vậy, các bản cập nhật chương trình sẽ không phải là nguồn duy nhất cho sự cố - và tìm ra cách thực hiện cập nhật một cách an toàn sẽ chỉ làm tăng thiệt hại mà bạn gặp phải khi thất bại đến từ một nguồn khác nhau.

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.