Phát triển trên một máy chủ sản xuất

Hôm nay tôi đã hét lên vì đã phát triển một ứng dụng trên một máy chủ sản xuất. Trích dẫn, " phát triển trên một máy chủ sản xuất là không thể chấp nhận được - bao giờ hết! "

Đây là tình huống.

1. Tôi thiết lập một ví dụ phát triển: http://example.com:3000
2. Ví dụ sản xuất là: http://example.com
3. Tôi hoàn thành tất cả công việc phát triển của mình http://example.com:3000và khi khách hàng hài lòng với những thay đổi, tôi chuyển chúng sang http://example.com.

Ứng dụng tôi đang làm việc là một ứng dụng Ruby on Rails cũ và tôi phải nói rằng ban đầu, tôi đã cố gắng thiết lập một môi trường phát triển cục bộ, nhưng tôi không bao giờ có thể chạy nó. Sau khi thử một lúc, tôi đã từ bỏ và quyết định phát triển trên máy chủ sản xuất.

Một lần nữa, tôi có phải là một thằng ngốc không? Có lẽ là như vậy, nhưng tôi đã thực hiện phát triển web trong một vài năm nay và tôi chưa bao giờ gặp phải tình huống như thế này. Ai đúng và tại sao?

Tôi đã từng phát triển trên máy chủ sản xuất. Nó có thể hoạt động tốt, nhưng không thể tin được vì ít nhất hai lý do:

1. Mã phát triển có thể gây ra các vòng lặp vô hạn, rò rỉ bộ nhớ hoặc các vấn đề khác làm khóa CPU, ăn hết bộ nhớ hoặc ảnh hưởng đến máy chủ theo cách sẽ ảnh hưởng đến mã sản xuất của bạn.
2. Nếu bạn cần thay đổi các thành phần của môi trường máy chủ như là một phần của công việc phát triển của bạn, như phiên bản của Ruby hoặc MySQL hoặc bất cứ điều gì, bạn sẽ bị ràng buộc.

Như những người khác đã tuyên bố, mã hóa trên môi trường SẢN XUẤT khiến người dùng của bạn gặp phải lỗi của bạn. Ngay cả khi bạn đã bắt đầu một phiên bản khác, bạn vẫn có tài nguyên phần cứng được chia sẻ và vẫn có thể truy cập các tệp và cơ sở dữ liệu sản xuất. Và như một số ý kiến ​​chỉ ra, nếu đối tượng Dev của bạn bị hack (ví dụ: vì bạn quên xóa nó và sau đó ai đó phát hiện ra một khai thác bảo mật lớn trong Rails), giờ đây bạn đã có một máy có thể truy cập công khai với ứng dụng của bạn hoạt động như một cửa ngõ vào. Điều đó sẽ ... không may.

Các doanh nghiệp khác nhau có phản ứng khác nhau về vấn đề này, nhưng nó có thể được chia nhỏ như thế này:

• Đã xảy ra một vụ lừa đảo?
• Sẽ mất bao lâu để hoàn nguyên một thay đổi (Tôi chủ yếu làm việc trong C ++, do đó, việc khôi phục lại một nhị phân có thể mất nhiều thời gian hơn so với trong Ruby, đặc biệt là khi bạn "mất" nhị phân cũ và phải biên dịch lại)
• Có gì ảnh hưởng của sự thay đổi (hướng dẫn sơ bộ: điều chỉnh các dữ liệu lưu trữ là rất tồi tệ hơn nhiều so với không lưu trữ hoặc hiển thị dữ liệu, do đó là tồi tệ hơn không hiển thị trang ở tất cả)
• Nếu bạn vặn vít rồi bước ra khỏi cửa, có ai biết bạn đã làm gì không?
• Có một tùy chọn triển khai nào khác có thể ngăn chặn / giảm thiểu / phát hiện sự vặn vít trước khi va chạm không?

Điều này cung cấp cho bạn tính toán cuối cùng:

• Làm thế nào nhiều vít này hoàn toàn có thể ngăn chặn được có chi phí kinh doanh?

Bây giờ đây là toàn bộ cấu trúc quản lý của bạn đáng giá bao nhiêu đối với anh chàng đưa ra quyết định ngân sách. Do đó hét lên.

Nếu bạn đang làm việc trên trang "Giới thiệu" nội bộ của công ty và đánh máy tên của bạn thành L. "giống như Chúa", vấn đề về biệt danh đáng xấu hổ; nếu bạn đang làm việc trên ứng dụng mua hàng quan trọng cho doanh nghiệp và cuối cùng nó vô tình gỡ lỗi văn bản chi tiết thẻ tín dụng cho trang chủ ... vấn đề kiện tụng. Giữa những thái cực đó là tất cả mọi thứ từ việc tăng giá sai, làm giảm năng suất và tất cả những thứ khác có thể khiến khách hàng bỏ đi.

Lý do không cho phép nó ngay cả đối với trang "Giới thiệu" là vì mã hóa trực tiếp trong sản xuất gây nghiện . Bạn bắt đầu bằng cách chỉ làm điều đó cho trẻ vị thành niên, nhưng theo thời gian, sẽ nhanh hơn rất nhiều khi không phải làm cho DEV env bị trầy xước.

Ngoài ra, quy mô của doanh nghiệp có thể có ảnh hưởng lớn. Trong một đội gồm hai người, khi có điều gì đó không ổn, bạn dựa vào vai bạn và nói "Ôi, đồ ngốc, đặt nó lại". Trong một công ty 300 người, bạn phải bắt đầu lo lắng về việc đó là sự bất tài hay ác ý, các nhà quản lý có thể chịu trách nhiệm về những thứ họ không kiểm soát được, v.v.

Vào cuối ngày, nếu bạn làm theo quy trình và làm hỏng, họ sẽ kiểm tra xem có gì sai với quy trình. Nếu bạn làm thủ tục và làm hỏng việc, giờ đây bạn chỉ có trách nhiệm, ngay cả khi sự đổ lỗi được lan truyền ra một chút. Cho dù bạn muốn tung xúc xắc trên đó là tùy thuộc vào bạn.

Tôi đã cố gắng thiết lập một môi trường phát triển cục bộ, nhưng tôi không bao giờ có thể chạy nó. Sau khi thử một lúc, tôi đã từ bỏ và quyết định phát triển trên máy chủ sản xuất.

Tôi NÊN hỗ trợ các tuyên bố để phát triển AVOID trên một máy chủ sản xuất. Bạn chỉ có thể được biện minh để thực hiện theo GUN, nếu đó là sửa lỗi chính tả trong tệp cấu hình và được người quản lý của bạn nhấn mạnh.

WHY NOT?- Bởi vì, rất nguy hiểm và trở thành thói quen sau này sẽ khiến bạn trở nên tồi tệ. Bởi vì, lỗi / thất bại trong sản xuất có thể khiến bạn bị sa thải khỏi công việc.

Hãy để tôi nhắc lại lần nữa, ngay cả khi bạn yêu cầu sửa lỗi chính tả trên productionmáy chủ, trước tiên hãy thực hiện Staging. hoặc nói cách khác kiểm tra các thay đổi của bạn, kiểm tra nó và kiểm tra lại trước khi đưa vào sản xuất.

Đây là điều thường xảy ra ở những nơi mà văn hóa "làm nhanh và bẩn " dường như là một chuẩn mực.

Chỉnh sửa: Phát triển trên máy chủ sản xuất, như một môi trường riêng biệt cũng KHÔNG được chấp nhận . Bất kỳ vấn đề nào gây ra trong công việc của bạn chỉ có thể làm sập máy chủ sản xuất và ảnh hưởng đến hiệu suất ứng dụng sản xuất . Ví dụ, tôi nhớ một trường hợp khi có lỗ hổng bảo mật, khi đồng nghiệp trước đó của tôi đã cố gắng sử dụng máy chủ sản xuất WinServer 2003 cho mục đích phát triển.

Đây thực sự là một vấn đề giao thức. Nói chung, đây không phải là điều mà bạn muốn làm. Bạn muốn để máy sản xuất một mình. Chúng có thể chứa dữ liệu nhạy cảm và bạn không muốn ảnh hưởng đến hiệu suất hoặc tính ổn định của các trang web sản xuất với mã sẵn sàng không sản xuất.

Điều đó nói rằng, có những lúc điều này thường được thực hiện. Nếu bạn đang ở trong một vị trí mà bạn đang bơm ra brouchurware lưu lượng truy cập thấp hoặc các trang web CMS đơn giản, điều này có thể sẽ ít gặp vấn đề hơn. Nhưng nếu bạn đang làm việc trên bất cứ thứ gì có dữ liệu nhạy cảm hoặc các quy trình "quan trọng trong kinh doanh", bạn thực sự không nên mạo hiểm khi có mã phát triển trên cùng một máy.

Một lý do quan trọng khác để không phát triển trực tiếp trong sản xuất là một thể hiện phát triển thường sẽ tạo ra và hiển thị các lỗi dài dòng và dấu vết ngăn xếp. Bạn không bao giờ muốn phơi bày điều đó cho người dùng.

Có, bạn có thể đăng nhập họ thay vì hiển thị chúng cho khách hàng, nhưng điều đó làm cho gỡ lỗi mà nhiều ít gây cười hơn nó đã là.

Đã thêm Giải quyết vấn đề phụ của bạn khi gặp sự cố với phiên bản phát triển của bạn: Tôi đã thành công khi triển khai máy ảo dựa trên VirtualBox , sao chép môi trường sản xuất của chúng tôi (tất nhiên không bao gồm phần cứng) với Máy chủ Ubuntu .

Tôi khá ngạc nhiên khi không ai đề cập đến lý do quan trọng nhất, tại sao nó hoàn toàn bị cấm phát triển trên các máy chủ sản xuất:

Đừng lộn xộn với dữ liệu sản xuất, điều này có thể xảy ra rất dễ dàng!

Một lỗi nhỏ ở một nơi dẫn đến những rắc rối lớn trong các tính toán khác và sau đó, vào ngày hôm sau, tất cả dữ liệu là rác và khách hàng tức giận. Điều này là rất nhiều, tồi tệ hơn nhiều so với một lỗi trong giao diện người dùng hoặc một sự cố nhỏ ở đây và đó.

Đối với hầu hết các ứng dụng, giá trị nằm trong dữ liệu chứ không phải trong các thói quen.

Tôi luôn cố gắng và hỏi các nhà phát triển khác các thủ tục dành cho công ty cụ thể. Nói chung là có, bạn nên luôn luôn:

1. Xây dựng tại địa phương.
2. Đẩy nó vào một số loại hộp bắt chước sản xuất càng nhiều càng tốt để xem nó có đẹp không.
3. Có thể đẩy nó đến một QA hoặc ví dụ chứng nhận để chuyển cho nhóm khách hàng / QA để xem xét các thay đổi.
4. Đẩy vào sản xuất.

Bạn có thể sử dụng công thức nấu ăn Capistrano kết hợp với GitHub để xử lý tất cả những thứ này cho bạn. Nếu bạn phải làm điều này bằng tay mỗi lần, nó có thể già đi nhanh chóng.

Một vấn đề khác khi phát triển trên prod là, đôi khi, những điều này bị bỏ sót trong kiểm soát nguồn và bản phát hành trong tương lai có thể hoàn tác thay đổi sửa chữa nhanh của bạn.

Nếu bạn đang ở trong một công ty giao dịch công khai ở Mỹ, bạn thậm chí không nên truy cập vào prod vì lý do quy định. Nói chung, không có công ty nào nên nhà phát triển có quyền truy cập prod (đối với các đại lý được nêu trong tất cả các câu trả lời cũng như lý do pháp lý có thể), vì vậy người quản lý của bạn cũng đã sai khi cho phép bạn quyền đối với máy chủ đó.

Các quy tắc sử dụng "luôn luôn" hoặc "không bao giờ" thường không được xác định rõ ràng. Sẽ có trường hợp cạnh mà phá vỡ một thực hành tốt nhất sẽ được biện minh. Lời khuyên tốt hơn sẽ là "Đừng chạm vào các máy chủ sản xuất trừ khi bạn có lý do rất chính đáng"

Trong sự nghiệp của tôi, tôi chỉ tìm thấy hai lý do để thay đổi mã trên các máy chủ sản xuất:

1. Lỗi hoặc hành vi chỉ xảy ra ở đó và không thể tái tạo trên môi trường phát triển. Đây là những thứ hiếm nhưng có thể rất khó chịu và khó tìm.

2. Trực tiếp sửa lỗi nghiêm trọng mà bạn không thể đủ khả năng để chờ để vượt qua quá trình triển khai thông thường nếu mất hơn một vài phút. Sau này đã được xóa với quản lý. Nếu bạn may mắn, bạn chỉ nên có một vài trong số đó cho toàn bộ sự nghiệp của bạn.

Cả hai đều tốt nhất để lại cho các nhà phát triển cao cấp biết các hệ thống một cách mật thiết.