Tại sao các nhà phát triển không thể triển khai trực tiếp vào sản xuất?

Question

Tôi luôn làm việc trong môi trường mà các nhà phát triển phải trải qua một quá trình làm việc với Network Operations (các máy chủ) để triển khai các công cụ từ phát triển/thử nghiệm đến sản xuất.

Gần đây tôi đã bắt đầu một công việc mà các nhà phát triển có thể đi trực tiếp từ máy của họ sang sản xuất mà không có người trung gian. Có lý do nào khiến các nhà phát triển không thể thực hiện được điều này?

Những gì tôi có cho đến nay:

• Bạn đang cẩn thận hơn về việc triển khai gì đó nếu nó phải trải qua người khác. Là một lập trình viên trẻ tuổi , đôi khi tôi mất một vài lần thử để có được triển khai hoạt động. Kể từ những người NetOps đã tức giận Tôi đã học được để đảm bảo rằng nó đúng ngay trong thời gian đầu tiên.

• Có một số trách nhiệm giải trình nếu xảy ra sự cố và nhiều người biết điều gì đang xảy ra. Boss: "Trang web vừa bị hỏng!", Mọi người khác trong văn phòng: "Abe vừa mới triển khai, đó là lỗi của anh ấy!"

• Khi ai đó chịu trách nhiệm duy nhất là máy chủ sản xuất, ít có khả năng là họ sẽ làm điều gì đó ngu ngốc.

• Sẽ có (hy vọng) có thêm thông tin về khả năng triển khai và cuộn lại. Nhật ký, bản sao lưu có thể được cuộn lại, các tính năng tự động ...

Có lý do nào khác không? Tôi chỉ là một con quái vật kiểm soát?

Answer 1

Nếu có một cách để làm cho một sai lầm Luật số lượng lớn, không hợp lý để đặt gánh nặng cho các nhà phát triển là hoàn hảo, nếu bạn cũng muốn họ làm việc hiệu quả.

• Quản lý thay đổi
• Trách
• QA
• Một nút xây dựng/triển khai
• Đơn vị kiểm tra sự ổn định
• Mã - giả sử bạn đẩy, ngay khi người khác chỉ cần kiểm tra trong mã?

Bây giờ, số tiền trên đầu/khó thay đổi phải liên quan trực tiếp đến các yêu cầu thời gian hoạt động của bạn. Nghỉ ngơi: thời gian chết càng tốn kém, bạn càng đầu tư nhiều hơn để ngăn ngừa thời gian chết.

Answer 2

Lý do chính là vì cho phép một dev triển khai trực tiếp để sản xuất cắt bỏ quy trình QA. Trong đó giới thiệu rủi ro. Loại quản lý nào không thích.

Vì vậy, một dấu đầu dòng khác cho bạn là sự gia tăng lớn trong RỦI RO.

Answer 3

Bởi vì nhiều nhà phát triển không thể suy nghĩ bẩm sinh khi nghĩ rằng họ mắc lỗi - cùng một lý do nhóm dev giỏi có đội ngũ kiểm tra chuyên dụng.

"Tôi sẽ chỉ thực hiện thay đổi cấu hình nhỏ này trong Sản phẩm, điều đó sẽ không làm hỏng bất kỳ thứ gì".

Các nhà phát triển OOP nên hiểu cách phân chia trách nhiệm, tôi đã nghĩ. Bạn phá vỡ nó, bạn sở hữu nó. Tránh vấn đề với một nhóm Ops riêng biệt.

Trong một số môi trường (ví dụ: tài chính) số tiền lớn (và đôi khi luật) cũng có nguy cơ bị thay đổi không được kiểm soát hoặc không có ý định trong môi trường sản xuất không được kiểm soát.

Trong các nhóm nhỏ, tôi có thể thấy một trường hợp cho các nhà phát triển có quyền truy cập sản xuất, nhưng điều đó phải được kiểm soát và kiểm tra để bạn LUÔN biết những gì đang trong Sản xuất. Trong ý nghĩa đó, không quan trọng ai đẩy các nút triển khai và rollback, nhưng chúng tồn tại và là chỉ cách để thay đổi môi trường sản xuất.

Tôi cho một người không muốn đó là một phần lớn công việc của tôi. Bạn có thể thấy rằng các nhà phát triển của riêng bạn đồng ý một khi họ thấy họ có thể chi tiêu bao nhiêu thời gian để viết mã.

Answer 4

Bằng cách triển khai trực tiếp vào môi trường sản xuất, có một cơ hội tốt là không có QA nào được tham gia (ví dụ: không có gì được kiểm tra).

Answer 5

Vì cần có MỘT người bạn có thể truy cập để biết ai được triển khai trên trang web. Nếu mọi nhà phát triển đều có thể triển khai, bạn không biết ai đã triển khai những gì khi ai đó nhận thấy có điều gì đó sai trái.

Answer 6

Một vài mà tôi suy nghĩ (có thể có sự chồng chéo với bạn):

• Một nhà phát triển có thể tinh chỉnh một cái gì đó cho đến khi nó hoạt động. Điều này không nên được thực hiện trong Sản xuất. Nếu nhà phát triển đó bị một chiếc xe buýt đâm vào ngày hôm sau, thì không ai biết hệ thống. Quy trình triển khai được lập tài liệu và có thể lặp lại bởi một ai đó khác giúp đảm bảo rằng các kiến ​​thức kinh doanh như vậy được ghi lại.
• Là nhà phát triển, tôi không muốn loại quyền truy cập đó. Nếu một cái gì đó thất bại, nó ít có khả năng đó là lỗi của tôi. Tôi sẽ đến và giúp đỡ, tất cả chúng ta đều ở cùng một đội, nhưng tôi muốn biết rằng một người khác đã phải xem xét công việc của tôi và đồng ý với nó. (Điều này cũng đúng với các kịch bản DB delta của tôi. Tôi muốn một DBA có đủ điều kiện hơn là cơ sở dữ liệu để xem xét lại công việc của tôi. cho tôi truy cập trực tiếp. Nó chỉ chậm hơn.)
• Các nhà phát triển thường thực hiện các bản sửa lỗi nhanh cho những thứ đơn giản. Chúng ta đều biết rằng nó thường không bị cắt và khô như ý nghĩ của nhà phát triển, và việc sửa chữa nhanh chóng đó đã không khắc phục được hoặc phá vỡ một thứ gì đó khác. Bất kể sự thay đổi/sửa chữa nhỏ như thế nào, vẫn có một quy trình QA. (Đối với một số cửa hàng mà thời gian hoạt động không quan trọng đến mức quy trình QA thực sự có thể là Sản xuất, nhưng đó là một ngoại lệ hiếm hoi. Nó không phải như vậy, từ góc nhìn thuần túy, nhưng với bất cứ thứ gì đó là tỷ lệ rủi ro/thưởng. rủi ro là thấp (như trong một thất bại sản xuất không phải chịu nhiều hình phạt nếu có ở tất cả) và chi phí của QA là tương đối cao, sau đó nó là tốt.)
• nhu cầu quy định. PCI tuân thủ, vv thường yêu cầu phân tách rõ ràng các nhiệm vụ giữa các công việc. Điều này thường được hiểu sai là "các nhà phát triển không thể truy cập vào sản xuất" và được xử lý rất đen và trắng. Nhưng điều đó có nghĩa là các nhà phát triển chỉ có thể truy cập vào những gì họ cần để thực hiện công việc của họ. Nếu bạn không cần dữ liệu sản xuất và dữ liệu đó nhạy cảm, bạn không nên có dữ liệu đó.

Answer 7

Bảo mật - Bằng cách có một gatekeeper (với bản sao lưu) chỉ một người đang truy cập dữ liệu sản xuất và máy chủ. Điều này có nghĩa là ít điểm truy cập hơn.

Dễ quản lý - Bạn không cần tạo nhiều tài khoản trong môi trường sản xuất để theo dõi - hoặc thậm chí tệ hơn, chia sẻ một tài khoản với nhiều tài khoản. (Giả định môi trường sản của bạn được tách ra khỏi môi trường dev của bạn

Thực hành làm cho hoàn hảo -.. Một người xây dựng một thói quen và gậy để nó có ít cơ hội cho thăng vít

Answer 8

tuân thủ SOC-1 có thể (không cần thiết) đề xuất hoặc yêu cầu nhà phát triển phải là người riêng biệt so với người phát triển để sản xuất để các biện pháp kiểm soát được thực hiện nhằm ngăn chặn mục đích xấu.