Làm thế nào tôi có thể tự động hóa việc triển khai sản xuất mà không gặp phải lo lắng cực độ?


32

Tại cửa hàng của chúng tôi, chúng tôi sử dụng SVN để kiểm soát nguồn và CruiseControl cho CI để xử lý các bản dựng và triển khai tự động cho các môi trường phát triển, thử nghiệm và tích hợp của chúng tôi.

Tất cả đều hoạt động trơn tru tuy nhiên do hạn chế về phần cứng và tài nguyên, môi trường tích hợp của chúng tôi không phải là môi trường cân bằng tải 2 máy chủ như môi trường sản xuất của chúng tôi. Trong khi mọi thứ khác đều bằng nhau, đó sẽ là điểm khác biệt duy nhất giữa môi trường sản xuất và tích hợp của chúng tôi (mặc dù là một môi trường lớn!)

Về mặt lý thuyết, sự khác biệt là một cấu hình hơi khác so với các máy chủ ứng dụng của chúng tôi và tập lệnh triển khai sẽ chỉ phải thả các tạo phẩm xây dựng vào hai máy chủ thay vì chỉ một, nhưng tại sao tôi lại lo lắng tự động hóa việc triển khai sản xuất của chúng tôi?!

Tôi nói chung không phải là một người thích kiểm soát nhưng tôi luôn cảm thấy cần phải triển khai sản xuất để sản xuất thủ công. Tôi đã được nghe từ các đồng nghiệp rằng đây thường là một BAD Thing ™ thực sự nhưng họ đã thất bại trong việc chống lại nó.

Tôi biết rằng khi tôi thực hiện thủ công, tôi có thể THẤY rằng tôi đang sao chép chính xác các tệp chính xác, tôi đang tắt máy chủ ứng dụng và đảm bảo chúng đóng thành công, tôi thực sự khởi động các máy chủ sao lưu và sau đó kiểm tra thực tế các bản ghi để thực hiện chắc chắn rằng nó đã khởi động ổn và việc triển khai đã thành công. Nó cho tôi một sự an tâm.

Các đối số chống lại đối số HOẶC này để triển khai sản xuất theo kịch bản tự động là gì?


'ls' sau 'rm' một lần cho phép tôi bắt được một rm thảm họa đang tái diễn thông qua các liên kết cứng đến các vị trí cao hơn trong hệ thống tệp. Đã có thể bắt được nó trong khi có đủ hệ thống còn lại để sử dụng để khôi phục các tệp đã bị xóa (việc xóa hàng triệu tệp dường như mất một thời gian may mắn!). :-)
Brian Knoblauch

Câu trả lời:


30

Có một vài lập luận rõ ràng chống lại điều này.

  1. Điều gì xảy ra nếu bạn rời đi. Là tất cả các thông tin này được ghi chép cẩn thận, hoặc nó chủ yếu là trong đầu của bạn. Kịch bản tự động là một nơi tốt hơn nhiều để người khác tiếp quản.

  2. Ai cũng mắc sai lầm. Sẽ đến lúc người thực hiện triển khai mệt mỏi, không chú ý gì cả. Có triển khai lý tưởng chỉ được thực hiện ở một nơi bình tĩnh hạnh phúc với nhiều thời gian. Trong thực tế, họ có thể vội vã và căng thẳng khi cố gắng đưa ra các bản sửa lỗi khẩn cấp. Đây là thời gian có khả năng nhất để phạm sai lầm, và cũng tốn kém nhất. Nếu việc triển khai là một tập lệnh đơn thì khả năng xảy ra lỗi là hạn chế.

  3. Thời gian. Khi việc triển khai trở nên phức tạp hơn, số lượng cần thực hiện tăng lên. Các kịch bản chỉ yêu cầu khởi động, kiểm tra thủ công và sau đó chuyển đổi thủ công (bạn cũng có thể tự động hóa việc này, nhưng tôi chia sẻ một số điều hoang tưởng :).


21

Bạn có thể có được những điều tốt nhất của thế giới tốt nhất: sự an tâm với xác minh quá trình và độ tin cậy của tự động hóa.

Kịch bản triển khai. Sau đó, đi qua và xác minh thủ công rằng các quy trình được bắt đầu, các tệp bị xóa, v.v. Nói cách khác, hãy viết tập lệnh QA của riêng bạn chỉ để xác minh rằng các bước tự động 1 - X thực sự đã xảy ra.


7
Có thể một cái gì đó giống như tạo Wizard của riêng bạn, nơi bạn có thể kích hoạt thủ công từng bước. Một đầu ra nhật ký được tạo ra với càng nhiều chi tiết bạn cần xác minh trước khi chuyển sang bước tiếp theo.
JeffO

@JeffO Tôi thích ý tưởng đó! Chúng tôi chỉ đầu tư vào một công cụ xây dựng GUI GUI đẹp mắt mà tôi dành cho mọi lý do để sử dụng nó. Tôi đang sử dụng các công cụ GUI nhanh hơn bao giờ hết và một trình hướng dẫn trực quan sẽ là thứ gì đó tuyệt vời đến mức một nhà phát triển cơ sở có thể xử lý nó.
maple_shaft

@maple_shaft Và bạn có thể hiểu được bước mà họ sao chép các tệp chính xác đã được thực hiện đúng lúc.
JeffO

Tôi đồng ý với điều này. Một cái gì đó đơn giản như một tệp bó (hoặc loạt chúng) để triển khai cho bạn có thể giảm bớt căng thẳng rất nhiều. Sử dụng các tệp bó để đảm bảo rằng bạn không mắc lỗi nào và chạy thủ công để đảm bảo rằng không có bất kỳ lỗi nghiêm trọng nào trong khi chạy các tệp bó.
Kibbee

4
@Jeff O - Tôi thích ý tưởng đăng nhập. Điều này tạo ra khả năng truy xuất nguồn gốc và cũng cung cấp cho maple một cái gì đó cho QA. Tôi không thích ý tưởng thuật sĩ. Càng nhiều bước để xuất bản sản phẩm của bạn lên sản xuất, càng có nhiều khả năng ai đó sẽ làm hỏng nó. Chỉ cần tự động hóa tất cả. Kiểm tra nó với con người.
P.Brian.Mackey

15

Tôi nghĩ chìa khóa ở đây là: tại sao bạn nghĩ rằng bạn không thể viết kịch bản quy trình xác minh?

Các kịch bản triển khai của tôi không chỉ đẩy tài liệu lưu trữ và khởi động lại dịch vụ. Họ in ra nhiều thông tin được mã hóa màu trong mỗi bước triển khai và cung cấp cho tôi bản tóm tắt các sự kiện ở cuối. Nó cho tôi biết rằng các quy trình đang hoạt động và đang chạy, trang chủ đang phục vụ 200 mã trạng thái và tất cả các máy và dịch vụ có thể thấy nhau tốt. Sau đó, tôi có một dịch vụ riêng không phải là một phần của tập lệnh theo dõi các tệp nhật ký, lỗi cấp 4xx và 5xx và số liệu trang web chính. Sau đó, nó tiến hành la mắng tôi qua mọi phương tiện có thể (email, tin nhắn txt và báo động) nếu có những đột biến có tác động tiêu cực mạnh mẽ.

Giữa điều đó và các máy chủ CI đang chạy thử nghiệm, tôi thực sự triển khai và quên ở mức độ tự động hóa này. Tôi thậm chí không duyệt một trang trên trang web sau một lần thúc đẩy vì quá trình này đáng tin cậy như thế nào, điều này không chỉ cho phép tôi triển khai thường xuyên như tôi muốn, mà còn cho phép một nhà phát triển mới trong dự án cập nhật trực tiếp trang web trong vòng vài phút sau khi lên tàu. Trước đây, tôi thậm chí đã làm cho các máy chủ CI tự động triển khai để sản xuất sau khi cam kết với một nhánh chính / thân cây vượt qua mọi thứ. Đó là cách tôi tự tin vào các công cụ của mình.

Bạn cũng nên như vậy.


1
Tôi ước tôi có thể có mức độ tự tin này nhưng không tin tưởng vào các công cụ ngăn chặn điều này, đó là niềm tin vào chất lượng của ứng dụng mà tôi được thừa hưởng và bản chất "Primadonna" của nó sau khi được triển khai. Tất nhiên những gì bạn mô tả là giấc mơ ướt của tôi và là trò chơi kết thúc mà tôi đang tìm kiếm.
maple_shaft

@maple_shaft Vâng, nếu đó là một ứng dụng cũ với phạm vi kiểm tra không đầy đủ, tôi chắc chắn có thể thấy muốn thực hiện can thiệp thủ công, đặc biệt nếu nó được biết là rất khó.
Pewpewarrows

1
Một trong những phương pháp tốt để chuẩn bị tập lệnh là chỉ cần ghi lại một trong các triển khai vào một tệp, đầu vào và đầu ra, sau đó sửa đổi nó để bao gồm quét đầu ra cho các sự kiện bạn thường kiểm tra bằng mắt.
SF.

8

Bạn cũng chạy các máy sản xuất của mình với gỡ lỗi từ xa, và bạn tự bước qua chúng? Xây dựng một kịch bản phù hợp giống hệt như viết một chương trình. Tất cả các vấn đề bạn có chỉ ra những điều mà nó sẽ cần phải theo dõi và kiểm tra lại.

Nếu có sự cố xảy ra, cần thực hiện các quy trình khôi phục thích hợp và gửi tin nhắn cho bạn. Tất cả mọi thứ xảy ra có thể được đăng nhập cho sau này. Phiên bản bạn có thể kiểm soát các tập lệnh và thiết lập các trường hợp thử nghiệm.

Nhưng nếu bạn đang chạy các lệnh thủ công, bạn không có bất kỳ lợi thế nào trong số này. Thay vào đó bạn có một danh sách các nhược điểm.

  • Bạn không có nhật ký tốt, lịch sử shell không được tính
  • Không ai biết làm thế nào để làm điều đó
  • Các bước bị bỏ lỡ
  • Kiểm tra chỉ đôi khi được thực hiện
  • Một số mục để triển khai có thể bị bỏ lỡ, tôi đã làm điều đó trước đây
  • Mất nhiều thời gian hơn
  • Bạn có thể bị gián đoạn trong quá trình

Một tập lệnh thích hợp sẽ gần giống với nếu bạn gõ mọi thứ trên vỏ. Đây là một trong những lý do mà chúng tôi có các tập lệnh bash. Nếu bạn tin tưởng vào những việc bạn làm, tại sao bạn không thể ghi lại mọi thứ và thắt chặt nó? Kiểm tra tốt hơn, kiểm tra nhanh hơn, kiểm tra nhiều hơn có thể xảy ra vì máy tính làm điều đó.


7

Tôi có thể hiểu được một chút lo lắng khi thử một cái gì đó mới trên môi trường prod. Cảnh giác với thảm họa tiềm tàng là một TM tốt .

Kịch bản tự động cũng là một TM tốt và miễn là bạn tiếp cận nó một cách cẩn thận, bạn sẽ có thể giảm thiểu nguy hiểm và giảm bớt nỗi sợ hãi. Vì vậy, lời khuyên của tôi là này;

  • Chuẩn bị (và thực hành về tích hợp env) một danh sách kiểm tra / bộ kiểm tra để bạn có thể nhanh chóng tìm hiểu xem nó có hoạt động không và nếu có vấn đề gì xảy ra. Ghi nhật ký chi tiết có thể giúp với điều này.
  • Sao lưu mọi thứ. Chuẩn bị và thực hành một rollback thủ công để bạn có thể phục hồi nếu nó đi sai.
  • Kiểm tra càng nhiều càng tốt trước khi bạn làm điều đó thực sự trên prod. Âm thanh như bạn là một cách tốt cùng với điều này với env tích hợp của bạn.
  • Lần đầu tiên bạn thử nó, làm nó trên một cấu hình thấp, thay đổi tác động thấp. Một cái gì đó như một nâng cấp nhỏ hoặc bản vá. Ý tưởng là để giảm thiểu bụi phóng xạ nếu nó đi sai. Không chọn nâng cấp lớn cấu hình cao (nơi CEO và tất cả các đối thủ của bạn đang xem) cho lần chạy đầu tiên của bạn.

Khi bạn đã có một vài lần chạy thành công trong vành đai của mình, sự tự tin của bạn sẽ tăng lên và chẳng mấy chốc bạn sẽ tự hỏi làm thế nào bạn từng quản lý việc triển khai thủ công.


1
Tôi nghĩ rằng câu trả lời của bạn là một trong những câu hỏi hay nhất, bởi vì nó thực sự làm giảm sự lo lắng trong khi hầu hết các câu trả lời khác đều lạc đề, ủng hộ việc triển khai tự động, điều mà OP nhận thức được. Vì vậy, câu trả lời của bạn xứng đáng với tiền thưởng!
dùng40989

4

Đây là lập luận lớn nhất chống lại việc triển khai thủ công vào sản xuất: Bạn là người và sẽ phạm sai lầm. Chắc chắn sẽ có lúc bạn quên làm điều gì đó sẽ khiến bạn đau buồn. Một triển khai tự động được viết tốt không có cùng xu hướng. Đúng là bạn vẫn có thể có các triển khai sản xuất lộn xộn, nhưng đó là vì việc triển khai tự động của bạn có các lỗi cần được giải quyết.

Theo kinh nghiệm của tôi, lợi ích của việc triển khai tự động đối với sản xuất là rất lớn. Điều lớn nhất là bạn có được niềm vui vào cuối tuần thay vì cố gắng diễu hành qua một quy trình triển khai thủ công không hợp tác.

Điều đó nói rằng, đây là một số gợi ý chính để tự động hóa việc triển khai sản xuất của bạn:

  • Đừng làm tất cả cùng một lúc! Bắt đầu từ từ viết các triển khai tự động của bạn. Trước tiên hãy thiết lập một môi trường phi sản xuất riêng biệt và thử tự động hóa các triển khai ở đó. Khi bạn đã tự tin xây dựng các triển khai tự động của mình, bạn có thể bắt đầu suy nghĩ về việc triển khai sản xuất
  • Bắt đầu phát hành và triển khai rất thường xuyên! Việc triển khai tự động sẽ dễ dàng hơn nhiều khi bạn không có 4 tháng mã chờ phát hành. Phát hành các tính năng nhỏ và sửa lỗi nhiều lần mỗi tuần. Những lợi ích của phong cách phát hành này không thể được đánh giá cao!
  • Dựa vào các bài kiểm tra tự động để giúp bạn tự tin rằng môi trường sản xuất của bạn sẽ hoạt động. Một lần nữa, điều này cần có thời gian để xây dựng, nhưng rất quan trọng. Kiểm tra tự động luôn tốt hơn so với kiểm tra chấp nhận thủ công. Chắc chắn, kiểm tra chấp nhận thủ công là tốt, nhưng kiểm tra tự động có thể giúp bạn biết liệu bạn có nên triển khai vào sản xuất hay không. Chúng là chìa khóa cho phép toàn bộ quá trình giao hàng tự động, liên tục này. Nếu các thử nghiệm của bạn không vượt qua, bạn biết không triển khai vào sản xuất.

3

Chạy các kịch bản trên máy chủ trực tiếp. Nó sẽ hoạt động và sau khi bạn thấy nó hoạt động tốt một vài lần, bạn sẽ hoàn toàn tin tưởng vào nó.

Nghiêm túc mà nói, bạn có nhiều khả năng mắc lỗi hơn so với kịch bản triển khai.


3

Máy tính không mắc lỗi, mọi người làm.

Viết kịch bản của bạn một lần và kiểm tra kỹ lưỡng nó, đi qua từng dòng một. Từ đó trở đi bạn có thể chắc chắn rằng mỗi lần bạn triển khai, nó sẽ hoạt động.

Làm điều đó bằng tay và bạn bị ràng buộc để phạm sai lầm. Có thể bạn đã viết, tất cả mọi thứ bạn phải làm, xuống nhưng thật dễ dàng để phạm sai lầm. Bạn phải sao chép tất cả các tệp ngoại trừ tệp web.config? Bạn có thể đặt cược rằng một ngày nào đó bạn sẽ ghi đè lên nó. Một kịch bản sẽ không bao giờ phạm sai lầm này.


3

Làm thế nào tôi có thể tự động hóa việc triển khai sản xuất mà không gặp phải lo lắng cực độ?

Sự lo lắng tột độ mà bạn sẽ gặp phải khi tự động hóa việc triển khai sản xuất, rất có thể, dựa trên hai niềm tin:

  1. Ngày này hay ngày khác, một số bước triển khai sẽ thất bại và bạn hoặc một người khác có thể phục hồi nhanh chóng từ thất bại trong khi một tập lệnh tự động có thể bỏ qua nó.

  2. Một thất bại bỏ qua trong sản xuất có hậu quả kịch tính.

Có rất ít người có thể làm khoảng 2., ngoài việc tránh những thất bại, vì vậy chúng ta hãy tập trung vào 1.

Một giải pháp giá rẻ cải thiện một chút về người tồn tại sẽ là sử dụng quy trình triển khai bán tự động, chờ xác nhận ở cuối mỗi bước cài đặt. Với giải pháp bán tự động, bạn sẽ được hưởng lợi ích của giải pháp hoàn toàn tự động, như tính nhất quán và khả năng tái tạo, trong khi bạn vẫn có cơ hội theo dõi tiến trình và phục hồi từ các lỗi như bạn hiện đang sử dụng.

Kịch bản bán tự động và biotope của nó (kiểm tra hồi quy, v.v.) cũng có thể đóng vai trò là phương tiện cho kiến ​​thức bạn đang thu thập về những thất bại xảy ra trong quy trình cài đặt và cách phục hồi từ chúng.


2

Điều tôi thích là bạn có thể kiểm tra việc triển khai trên dàn hoặc QA và biết rằng khi bạn chạy nó trên prod, các bước chính xác sẽ xảy ra.

Khi bạn thực hiện thủ công sẽ dễ dàng hơn để quên một bước hoặc thực hiện chúng không theo thứ tự.


Vấn đề là prod và dàn dựng và QA trông không giống nhau. Vì vậy, kịch bản sẽ làm những điều khác nhau trên mỗi môi trường. Vì vậy, kịch bản sẽ được thử nghiệm lần đầu tiên khi sản xuất.
Piotr Perak

Sau đó, thiết lập môi trường mà bạn làm mới từ Prod ngay trước khi bạn chạy tập lệnh tự động. Sử dụng nó cho không có gì khác.
HLGEM

Tôi không hiểu Nếu anh ta có thể thiết lập môi trường trông giống như SẢN XUẤT, anh ta sẽ không gặp vấn đề gì cả.
Piotr Perak

1

... Do hạn chế về phần cứng và tài nguyên, môi trường tích hợp của chúng tôi không phải là môi trường cân bằng tải 2 máy chủ như môi trường sản xuất của chúng tôi. Trong khi mọi thứ khác đều bằng nhau, đó sẽ là điểm khác biệt duy nhất giữa môi trường sản xuất và tích hợp của chúng tôi (mặc dù là một môi trường lớn!)

Đưa ra ở trên, tôi có thể sẽ lo lắng như bạn.

Tôi đã từng xem xét và thử nghiệm tập lệnh tự động triển khai cho SLB và cảm giác của tôi là không có kiểm tra trước khi thiết lập cân bằng tải, tôi thích làm thủ công hơn.


Bên cạnh thiết lập thử nghiệm giống như prod, một điều khác có tác động đáng kể đến sự an tâm của tôi là việc triển khai prod được thực hiện bởi nhóm khác mà các nhà phát triển - bởi những người chỉ có công việc duy trì môi trường sản xuất.

  • Trong một trong những dự án tôi đã hỗ trợ họ triển khai với tư cách là đại diện nhóm phát triển. Trước khi triển khai, họ đã xem xét hướng dẫn của tôi và trong quá trình triển khai, tôi chỉ ngồi trực tuyến sẵn sàng tư vấn nếu có sự cố. Hồi đó, tôi học cách trân trọng sự chia ly đó .
     
    Không phải là chúng nhanh hơn (tại sao chúng? Tôi đã thử nghiệm triển khai 5x-10x thường xuyên hơn chúng). Sự khác biệt lớn là tập trung. Ý tôi là, đầu tôi luôn bị tải bởi những thứ "chính" - mã hóa, gỡ lỗi, các tính năng mới - có quá nhiều phiền nhiễu để tập trung đúng vào việc triển khai. Trái ngược với điều đó, công cụ chính của họ chỉ là bảo trì sản xuất và họ tập trung vào đó.
     
    Thật đáng ngạc nhiên khi não hoạt động tốt hơn nhiều khi tập trung. Những người này, họ rất chu đáo, họ đã phạm lỗi ít hơn tôi rất nhiều. Họ chỉ biết những thứ đó tốt hơn tôi. Họ thậm chí còn dạy tôi một hoặc hai điều khiến việc triển khai thử nghiệm của tôi trở nên dễ dàng hơn.

Cảm ơn, thật tốt khi nghe từ một người biết cảm giác này như thế nào. Không cần phải nói rằng chúng tôi quá nhỏ để đảm bảo một nhóm xây dựng xử lý việc triển khai sản xuất của chúng tôi. Khi bạn làm việc tại một công ty khởi nghiệp, bạn học cách đội 20 chiếc mũ khác nhau khá nhanh và tôi không phải lúc nào cũng có sự "tập trung" xa xỉ. Tôi nghĩ rằng tôi sẽ viết một kịch bản triển khai và xác minh mạnh mẽ cho sự tỉnh táo của mình. Lần đầu tiên sau một thời gian, tôi có hai tuần tạm lắng giữa các dự án nơi tôi có thể hoàn thành công việc như thế này.
maple_shaft

kịch bản xác minh tôi thấy. Vâng, với tình hình của bạn, đây dường như là điều tốt nhất tiếp theo sau đội ngũ xây dựng chuyên dụng. Tôi tự hỏi btw bạn có thực sự không có tùy chọn để triển khai thử nghiệm trên thiết lập hai máy chủ không? ngay cả khi bạn bỏ qua bộ cân bằng tải, chỉ để kiểm tra khói mà cả URL chính / nô lệ đều phản hồi?
gnat

1

Xây dựng một kịch bản triển khai mà bạn sử dụng để di chuyển mã của mình vào bất kỳ môi trường nào. Chúng tôi sử dụng cùng một quy trình triển khai để di chuyển mã đến dev, qa, dàn dựng và cuối cùng là sản xuất. Vì chúng tôi đang triển khai nhiều lần mỗi ngày cho nhà phát triển và hàng ngày đến QA, chúng tôi đã có được sự tin tưởng rằng các tập lệnh triển khai là chính xác. Về cơ bản, kiểm tra địa ngục của nó bằng cách sử dụng nó thường xuyên.


1
  1. Đơn giản hóa. Quá trình thay đổi của bạn phải là các tệp rsync, chạy tập lệnh SQL, không có gì nữa.
  2. Tự động hóa.
  3. Kiểm tra.

Lý do để tự động hóa là để có được thứ gì đó có thể thử nghiệm, có thể lặp lại và bạn có thể tin tưởng để làm việc chính xác trong mọi tình huống dự kiến.

Bạn vẫn cần phải có một kế hoạch rút lui, như đối với bất kỳ thay đổi nào trong bất kỳ bối cảnh nào, và nó cũng nên được tự động hóa.

Bạn vẫn sẽ muốn quan sát quá trình khi nó xảy ra nếu môi trường thực sự nhạy cảm, nhưng không bao giờ thực hiện thủ công vì nó không thể được sao chép.


0

Hoàn toàn có thể sử dụng các tập lệnh tự động hóa để triển khai vào môi trường sản xuất. Tuy nhiên để làm được điều đó một cách đáng tin cậy, bạn cần có khả năng làm một số việc.

  1. Đáng tin cậy quay trở lại phiên bản trước.
  2. Có được xác nhận tích cực rằng việc triển khai đã được áp dụng thành công và đang phản hồi lưu lượng hợp lệ.
  3. Có môi trường tương đương để phát triển và QA cũng sử dụng các tập lệnh tương tự.

Có một số lợi thế cho các kịch bản, chẳng hạn như chúng sẽ không bao giờ bỏ lỡ một lệnh nào vì đã 2 giờ sáng và nó mệt mỏi.

Tuy nhiên, các kịch bản có thể và vẫn sẽ thất bại. Đôi khi sự thất bại nằm ở thiết kế của tập lệnh, nhưng nó cũng có thể do mạng hoặc sự cố mất điện, hệ thống tệp bị hỏng, hết bộ nhớ .....

Đó là lý do tại sao điều quan trọng là sau khi tập lệnh chạy, giai đoạn thử nghiệm được xác định cũng được theo dõi để xác minh rằng việc triển khai mới được thực hiện, chạy và xử lý các yêu cầu, trước khi lưu lượng truy cập trực tiếp được bật.


-2
  1. lấy một cửa sổ lớn hơn để triển khai lần đầu tiên nếu có sự cố
  2. Chia quá trình Triển khai thành hai phần. a. Sao lưu (thủ công) - điều này sẽ giúp bạn tự tin nếu có sự cố xảy ra trong quá trình triển khai

    b. Triển khai (tự động)

một khi bạn có thể tự tin triển khai lần đầu tiên. bạn có thể tự động hóa quá trình sao lưu là tốt.


điều này không trả lời câu hỏi được hỏi: "các đối số chống lại đối số HOẶC này để triển khai sản xuất theo kịch bản tự động là gì?"
gnat
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.