Làm thế nào để chuyển tập tin vào sản xuất?


9

Chúng tôi là một nhóm bắt đầu làm việc trên một trang web khá lớn với một cơ sở mã hiện có. Chúng tôi có một thử nghiệm và một máy chủ sản xuất.

Ý tưởng của chúng tôi là có một kho lưu trữ thử nghiệm với một số nhà phát triển có quyền truy cập đẩy vào; và một kho lưu trữ may mắn mà chỉ một số ít có thể đẩy đến. Repo may mắn được cho là luôn ổn định và đại diện cho phiên bản sản xuất mới nhất.

Làm cách nào tôi có thể tự động hóa quá trình chuyển các tệp vào sản xuất? Có phải là xấu khi có các tập tin sản xuất dưới sự kiểm soát phiên bản? Theo cách đó, đẩy vào kho lưu trữ may mắn có nghĩa là triển khai. Nhưng, điều gì xảy ra khi có xung đột hợp nhất? Máy chủ sản xuất sẽ phá vỡ cho đến khi nó được giải quyết?

Câu trả lời:


7

Nói một cách đơn giản:
Bản thân quá trình đẩy phải hoàn toàn tự động. Cho dù bạn có một số tập lệnh tùy chỉnh, hoặc bạn chỉ cần kéo từ repo "may mắn" vào môi trường sản xuất. Điều đó tùy thuộc vào bạn. Bạn chỉ nên có một cái gì đó tự động, bởi vì các quy trình tự động có thể được thực hiện đáng tin cậy (trái ngược với việc tải lên các tệp bằng tay và như vậy).

Tuy nhiên, quá trình đẩy nên được kích hoạt bằng tay. Bạn đẩy các bản cập nhật của mình và một khi bạn cảm thấy tự tin, bạn gắn thẻ nó như một ứng cử viên phát hành và kéo nó vào môi trường thử nghiệm của bạn (điều đó lý tưởng nhất là giống với môi trường sản xuất của bạn nhất có thể). Khi RC được thử nghiệm, việc đẩy có thể được bắt đầu.
Cho đến hôm nay, không có gì khác có thể cung cấp cho bạn, những gì người thử nghiệm có thể.

Điều này nghe có vẻ hơi chậm, theo nghĩa là vòng phản hồi là tương đối lớn. Nhưng để thử nghiệm đúng cách, điều quan trọng là phải chụp một ảnh chụp cố định, sau đó được kiểm tra trong 24-48h (hoặc có thể nhiều hơn, tùy thuộc vào quy mô của dự án). Ngược lại là một kịch bản, nơi bạn tìm thấy rất nhiều lỗi ngay sau khi đẩy và bạn cố gắng sửa nó bằng một số sửa chữa nhanh chóng giới thiệu các lỗi mới.
Bạn nên tạo một bản phát hành với các lỗi đã biết (có mức độ nghiêm trọng chấp nhận được), hơn là một lỗi có lỗi chưa biết (mức độ nghiêm trọng chưa biết).


Vì vậy, có một repo trên máy chủ sản xuất là OK? Khi tôi nói tự động hóa, tôi có nghĩa là trong trường hợp không có repo trên máy chủ sản xuất (nói cách khác, sẽ có thử nghiệmban phước cho các repos, nhưng không sản xuất ). Tất nhiên, thử nghiệm của con người không thể được tự động hóa, đó không phải là những gì tôi đang theo đuổi.
Tamás Szelei

1
@ Tamás: Có thể chấp nhận kiểm tra cục bộ của repo may mắn trên máy chủ của bạn, nếu đó là ý của bạn (apache (hoặc bất kỳ máy chủ web đàng hoàng nào khác) giúp bạn dễ dàng truy cập các tệp liên quan đến git từ bên ngoài). Tuy nhiên, bạn có thể dễ dàng thực hiện một "xuất khẩu" của nó. Không có điểm nào có tệp trong webroot của bạn, không thuộc về nơi đó.
back2dos

Err -... Vậy làm thế nào bạn biết chính xác những lỗi chưa biết về mức độ nghiêm trọng chưa biết là gì nếu chúng ... chưa biết ?
Spoike

@Spoike Tôi nghĩ back2dos chỉ đơn giản là ủng hộ việc kiểm tra kỹ lưỡng, sử dụng các bản phát hành cố định không có bản sửa lỗi "nhanh n bẩn" chưa được kiểm tra.
Tối đa

@Spoike: Trong 24-48h bạn có thể biến rất nhiều lỗi chưa biết thành lỗi đã biết. Cũng trong 5 phút, bạn có thể biến một lỗi đã biết thành rất nhiều lỗi chưa biết. Điều này được gọi là một sửa chữa nhanh chóng.
back2dos

2

Tôi đã học được rất nhiều về việc triển khai từ việc xem cách Capistrano vận hành. Tôi đã làm việc với RoR vào thời điểm đó, vì vậy đó là một lựa chọn hợp lý và mặc dù tôi chưa bao giờ thực hiện được nó để thực hiện dự án mà tôi đang thực hiện, cách nó thực hiện cập nhật tự động rất hữu ích.

Bạn có thể đang ở trong một tình huống mà bạn có thể sử dụng nó trực tiếp ngay cả - nó không nhất thiết phải gắn với Rails - nhưng nếu không, cách nó hoạt động chắc chắn là hữu ích.


1

Tùy thuộc vào nền tảng bạn đang sử dụng, có rất nhiều công cụ có thể giúp bạn sử dụng để tự động hóa các bản phát hành sản xuất. Tôi làm việc trong một cửa hàng .NET vì vậy chúng tôi đã sử dụng NAnt (mặc dù MSBuild là một lựa chọn tốt hơn hiện nay). Java có Ant và có thể những thứ khác. Ruby có những thứ như Rake. Sau đó, có các nền tảng tích hợp liên tục như TeamCity và Hudson cũng có thể được sử dụng để quản lý các bản phát hành.

Tôi chưa bao giờ thấy hoặc nghe nói về việc có mã prod trực tiếp trong một repo kiểm soát nguồn riêng biệt nhưng điều đó chắc chắn có thể hoạt động. Giống như back2dos đã nói, chìa khóa là tự động hóa. Chúng tôi có các tập lệnh xây dựng được thiết kế để kiểm tra từ kiểm soát nguồn, xây dựng và đẩy sang môi trường dàn dựng để thử nghiệm. Sau đó, khi chúng tôi thích cách dàn dựng hoạt động, các kịch bản sao chép từ QA sang Prod.

Đề nghị của tôi là xem xét các công cụ ngoài đó và chọn một công cụ, sau đó thiết kế một quy trình sẽ hoạt động tốt với công cụ đã chọn. Đừng cố gắng phát minh lại bánh xe quá nhiều - đây là một vấn đề rất được giải quyết.

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.