Tôi làm việc trong một nhóm lập trình nhỏ hỗ trợ một tổ chức lớn hơn. Năm nay, người quản lý của chúng tôi đã quyết định chúng tôi sẽ sử dụng các công nghệ Oracle Apex để xử lý phần lớn dữ liệu của công ty chúng tôi.

Điều này sẽ ổn, ngoại trừ chúng tôi chỉ có một máy chủ Apex. Người quản lý của chúng tôi đã ra lệnh rằng mọi thứ xảy ra trong trường hợp đó. Nhóm của chúng tôi đang phát triển ứng dụng, trong khi người quản lý của chúng tôi giới thiệu chúng và khách hàng nội bộ của chúng tôi sử dụng chúng, vì lý do rõ ràng đã gây ra sự cố!

Tôi chỉ có thể mong đợi điều này trở nên tồi tệ hơn khi chúng ta đầu tư nhiều hơn vào Apex, các ứng dụng trở nên phức tạp hơn và số lượng người dùng tăng lên. Tôi đã nghe nói rằng thực tiễn tốt nhất là có môi trường phát triển, thử nghiệm và sản xuất riêng biệt nhưng tại sao lại như vậy?

Câu hỏi: Tại sao chúng ta nên có môi trường phát triển, thử nghiệm và sản xuất riêng biệt?

Tại sao chúng ta nên có môi trường phát triển, thử nghiệm và sản xuất riêng biệt?

Bạn có một số hoạt động diễn ra đồng thời:

• phát triển - nơi các nhà phát triển cam kết mã, mắc lỗi, thử nghiệm, v.v ...
• thử nghiệm - nơi các thử nghiệm được chạy, thủ công hoặc tự động và do sự phức tạp, có thể tiêu tốn rất nhiều tài nguyên.
• sản xuất - nơi tạo ra giá trị cho khách hàng và / hoặc doanh nghiệp

Bạn có muốn tất cả những điều này xảy ra trong cùng một môi trường? Bạn có muốn doanh nghiệp ngừng hoạt động vì một thử nghiệm mới đã đẩy máy chủ của bạn vào trao đổi trên ổ cứng và đang tiêu tốn mọi lõi trên bộ xử lý? Bạn có muốn các bài kiểm tra của mình bị đình trệ vì một nhà phát triển đã tạo ra một quả bom nĩa hỗn độn từ một thí nghiệm mở rộng không? Bạn có muốn mã mà bạn nghĩ là có hiệu quả do dây bện và băng keo của nhà phát triển trong các thử nghiệm để chạy trong sản xuất không? Bạn có muốn các nhà phát triển làm việc với dữ liệu sản xuất có khả năng nhạy cảm (tôi biết đây không phải là mối quan tâm trong tất cả các doanh nghiệp, nhưng nó nằm trong rất nhiều trong số họ)?

Điều gì ngăn cản những vấn đề này xảy ra?

Môi trường riêng biệt.

Vì vậy, bạn cần những gì?

Bạn cần môi trường riêng biệt.

Để chính thức

Bạn cần môi trường riêng biệt vì những lý do sau:

• để giảm rủi ro ngăn chặn kinh doanh và phát triển phần mềm.
• để giảm rủi ro đưa mã vào sản xuất vượt qua các thử nghiệm do sự gian lận đặc biệt của nhà phát triển.
• để giảm rủi ro dữ liệu sản xuất rơi vào tay kẻ xấu (rất quan trọng khi các tổ chức xử lý dữ liệu nhạy cảm, như số ID và thông tin tài chính và sức khỏe) hoặc bị xen kẽ với dữ liệu thử nghiệm hoặc bị phá hủy.

Đối với bối cảnh của bạn, một nền tảng công nghệ mới

Có thể đây chưa thực sự là sản xuất (vì đây là một nền tảng tương đối mới), nhưng bạn sẽ có được môi trường riêng biệt khi doanh nghiệp bắt đầu dựa vào nó và họ đủ khôn ngoan để thấy trước rủi ro hoặc nhận ra điều đó bằng cách học hỏi chăm chỉ đường.

Tôi đã nghe nói rằng thực tiễn tốt nhất là có môi trường phát triển, thử nghiệm và sản xuất riêng biệt nhưng tại sao lại như vậy?

Nó không phải là cắt giảm rõ ràng những ngày này.

Nhiều nơi không thực hiện kiểm tra thủ công nữa, vì vậy không có dữ liệu kiểm tra mỗi lần. Nhiều nơi khác có quy mô như vậy, mà họ không thể tái tạo môi trường sản xuất của họ do chi phí. Và đặc biệt với sự phát triển bùng nổ của microservice, việc giữ cho môi trường thay đổi nhanh chóng không đồng bộ đủ để đảm bảo rằng thử nghiệm trong môi trường QA sẽ tái tạo mọi thứ một cách chính xác để bắt lỗi trong sản xuất.

Tại sao chúng ta nên có môi trường phát triển, thử nghiệm và sản xuất riêng biệt?

• Nếu người dùng nhìn thấy dữ liệu thử nghiệm của bạn sẽ rất tệ.
• Nếu có dữ liệu prod của bạn được nhìn thấy bởi các nhà phát triển / người kiểm tra sẽ rất tệ.
• Nếu bạn không thể tin tưởng các nhà phát triển của mình sẽ không phá vỡ mọi thứ một cách tồi tệ và bạn không thể khắc phục tình trạng đó một cách nhanh chóng.
• Nếu bạn có CI tự động tại chỗ sao cho việc quảng bá mã nhanh chóng và dễ dàng.

Về cơ bản, nếu chi phí có môi trường thấp hơn chi phí không có môi trường .

Lý do chính (và rõ ràng nhất) là bạn không bao giờ muốn trộn dữ liệu thử nghiệm và sản xuất. Điều này có thể gây nhầm lẫn rất nhanh cho cả người dùng hệ thống cũng như nhà phát triển. Khi bạn đang quản lý đảm bảo chất lượng và kiểm tra đơn vị (mà bạn nên làm), bạn cần đảm bảo rằng họ đang ở trong một môi trường hoàn toàn tách biệt. Nếu một cái gì đó bùng nổ trong môi trường phát triển của bạn hoặc trong QA, nó sẽ ảnh hưởng xấu đến sản xuất và do đó người dùng trực tiếp và dữ liệu quan trọng của họ! Bạn hoàn toàn không muốn điều này ảnh hưởng đến sản xuất!

Điều này mở rộng cho các dịch vụ bình thường mà bạn nên sử dụng trong công việc hàng ngày như kiểm soát phiên bản của bạn. Bạn không thể sử dụng kiểm soát phiên bản đúng cách nếu mã bạn đang kiểm soát ở trong môi trường trực tiếp! Người dùng của bạn sẽ phát điên - điều gì sẽ xảy ra nếu bạn cần hoàn nguyên hoặc khôi phục? Điều gì nếu bạn phạm một sai lầm nghiêm trọng mười lăm cam kết sâu sắc? Làm thế nào bạn sẽ xử lý phân nhánh?

Ít nhất, bạn nên tách môi trường của mình thành nhiều trường hợp ảo, nhưng bạn thực sự cần phải làm chính xác những gì bạn đã nói và có các trường hợp hoàn toàn riêng biệt cho từng môi trường; phát triển lý tưởng, QA, dàn dựng và sản xuất.

Tất cả những điều này cuối cùng gây ra sự bất lợi không chỉ cho ứng dụng trực diện của bạn (và do đó là uy tín của bạn với người dùng của bạn), mà còn cho hiệu quả của nhóm bạn.

Chỉ có một phiên bản Oracle khả dụng không có nghĩa giống như "không tách biệt giữa các môi trường phát triển, thử nghiệm và sản xuất"!

Bạn đã viết trong một bình luận

Chúng tôi hiện đang sử dụng các lược đồ khác nhau cho các dự án khác nhau

Ok, vì vậy bằng cách dành một số dự án chỉ để phát triển và một số để thử nghiệm, bạn có thể tách các môi trường của mình ở một mức độ nào đó, bằng cách sử dụng các lược đồ khác nhau. Tôi đoán bạn đã làm điều này, vì đây là cách tiếp cận hợp lý duy nhất tôi biết khi không có sự phân tách cá thể nào được lên kế hoạch. Tôi không thể tưởng tượng người quản lý của bạn điên rồ đến mức anh ta muốn bạn trộn lẫn dữ liệu dev, dữ liệu thử nghiệm và dữ liệu khách hàng trong một lược đồ theo cách cư xử tùy tiện. Anh ta có lẽ chỉ muốn tiết kiệm tiền bằng cách không mua máy chủ thứ hai hoặc đầu tư tiền vào giấy phép cho ví dụ thứ hai.

Do đó, câu hỏi thực sự bạn cần hỏi là:

Chúng ta có cần sử dụng các phiên bản và / hoặc máy chủ khác nhau để phân tách các môi trường phát triển, thử nghiệm và sản xuất hoặc phân tách lược đồ đủ không?

Điều đó làm cho câu trả lời không quá rõ ràng như trong các câu trả lời khác ở đây. Các lược đồ khác nhau cho phép các quyền truy cập khác nhau, do đó, ít nhất bạn có thể có được sự cô lập ở một mức độ nhất định bên trong một thể hiện của Oracle. Tuy nhiên, các nhà phát triển của bạn có thể sẽ cần một số quyền quản trị trong lược đồ "của họ", do đó sẽ khó đảm bảo họ sẽ không có quyền truy cập vào dữ liệu sản xuất nếu bạn chỉ sử dụng một phiên bản.

Hơn nữa, một cá thể / một máy chủ cũng có nghĩa là tài nguyên được chia sẻ giữa dev, test và sản xuất - quản trị lược đồ / người dùng chung, không gian đĩa chung, CPU dùng chung, băng thông mạng chia sẻ. Kết hợp điều này với "luật trừu tượng rò rỉ" , và rõ ràng rằng chỉ sử dụng một trường hợp sẽ có rủi ro nhất định nhận được các tác dụng phụ không mong muốn giữa môi trường dev, test và prod.

Cuối cùng, bạn phải tự quyết định: bạn có thể làm việc hiệu quả với những nhược điểm của phương pháp này không? Ứng dụng của bạn không quá mạnh về tài nguyên và dữ liệu sản xuất của bạn không "bí mật" đến mức có thể giảm mức độ phân tách giữa dev, test và sản xuất so với mức bạn có thể nhận được từ "ba trường hợp / ba máy chủ" tiếp cận? Nếu bạn không thể làm việc hiệu quả theo cách đó, hoặc không có rủi ro cao trong việc can thiệp sản xuất theo cách bạn bắt đầu mất khách hàng, bạn có tất cả các lý lẽ bạn cần để thuyết phục người quản lý của mình mua ít nhất một máy chủ thứ hai.

Bạn cần nhiều loại môi trường và thậm chí có thể nhiều máy chủ trong mỗi môi trường.

Các nhà phát triển có thể cập nhật mã trong phát triển. Mã thậm chí có thể không hoạt động - có lẽ ứng dụng thậm chí sẽ không bắt đầu.

Điều đó không ảnh hưởng đến QA, người đang thử nghiệm bản dựng ổn định mới nhất trong môi trường của chính họ.

Vì cả phát triển và QA đều đang cập nhật môi trường của họ, việc sản xuất được xây dựng trên bản phát hành mới nhất từ ​​sáu tháng trước và không bị ảnh hưởng bởi những thay đổi trong các môi trường khác.

Những thay đổi này được đưa ra trong các môi trường khác nhau có thể là mã hoặc dữ liệu. Có lẽ QA cần kiểm tra tập lệnh cơ sở dữ liệu được thiết kế để sửa một số dữ liệu xấu trong sản xuất. Có thể kịch bản làm cho vấn đề tồi tệ hơn - khôi phục bản sao lưu cơ sở dữ liệu và thử lại. Nếu điều đó xảy ra trong sản xuất, bạn có thể gặp vấn đề tài chính rất nghiêm trọng.

Điều gì xảy ra nếu bạn có nhiều bản phát hành? Có thể bạn đang phát triển phiên bản 2.0, nhưng vẫn cần bản phát hành sửa lỗi trên nhánh bảo trì 1.0. Bây giờ bạn cần nhiều môi trường phát triển và QA để đảm bảo bạn luôn có thể phát triển và kiểm tra một trong hai nhánh khi một lỗi nghiêm trọng được phát hiện và cần được sửa chữa vào ngày hôm qua.

Bạn đã nhận thấy những vấn đề không có môi trường riêng biệt gây ra. Ngay tại đó, bạn đã có lý do cơ bản cho các môi trường riêng biệt: để loại bỏ các vấn đề gây ra bởi các xung đột chắc chắn phát sinh khi cố gắng thực hiện các hoạt động phát triển, thử nghiệm và sản xuất trong một môi trường duy nhất. Lý do tương tự áp dụng cho việc cung cấp cho các nhà phát triển từng hộp cát riêng lẻ, nó giữ cho các nhà phát triển mắc lỗi hoặc thậm chí chỉ là những thay đổi không tương thích từ việc làm tê liệt toàn bộ nhóm phát triển.

Đây cũng là lý lẽ tốt nhất bạn có thể đưa ra để quản lý khi thay đổi khỏi môi trường đơn lẻ: chỉ ra các vấn đề mà môi trường đơn lẻ đã gây ra, hiển thị đường xu hướng và lập luận rằng sớm hay muộn nếu mọi thứ tiếp tục như chúng sẽ xảy ra vấn đề sẽ tốn nhiều chi phí hơn để dọn dẹp (cả trong nỗ lực trực tiếp và mất niềm tin của khách hàng vào khả năng cung cấp dịch vụ của công ty bạn) so với việc cấu hình lại mọi thứ cho các môi trường riêng biệt sẽ có chi phí.

Có nhiều lực lượng và động lực đối lập. Có chi phí để có nhiều máy chủ và chi phí chỉ có một. Tôi nghĩ rằng câu hỏi này có thể truyền tải nhiều hơn là cơ sở dữ liệu? Tôi có thể hiểu lầm, nhưng nó liên quan đến một sự hiểu lầm có hệ thống, đó là chi phí của tangibles và trừu tượng

Thông thường các chi phí rõ ràng là dễ hiểu.

Chi phí trừu tượng khó định lượng hơn và do đó khó hiểu hơn. TechnicalDebt, chi phí lỗi, chi phí căng thẳng, gánh nặng cho các nhà phát triển, ảnh hưởng của thay đổi, kiểm tra hồi quy, tác động của thời gian chết và như vậy là khó giải thích hơn.

môi trường khác nhau Môi trường thường được phân tách cho dữ liệu và / hoặc mục đích. Mỗi môi trường có một chức năng khác nhau. Tỷ lệ thay đổi trên một hệ thống, tức là. tần suất nó sẽ được cập nhật, loại thay đổi và ảnh hưởng của thay đổi, đều được xem xét.

Chúng tôi sử dụng các môi trường khác nhau để tầm thường hóa thay đổi.

Chúng tôi sử dụng các môi trường khác nhau, vì vậy chúng tôi cung cấp sự mạnh mẽ và chắc chắn của môi trường không thay đổi.

Chúng tôi sử dụng các môi trường để xem xét ảnh hưởng của một sự thay đổi.

Chúng tôi sử dụng môi trường để giảm chi phí liên quan đến thay đổi.

chi phí rất nhiều để kiểm tra và ổn định hệ thống Bạn tạo môi trường để bảo đảm khoản đầu tư được thực hiện trên môi trường ổn định.

Bạn không bao giờ là một nhóm quá nhỏ để tuân thủ các quy trình thực dụng, tiết kiệm chi phí, siêng năng và đã được chứng minh.

Sử dụng một môi trường cho mọi thứ giống như lưu trữ tất cả ảnh của bạn trên một ổ cứng, bạn có thể làm điều đó, nhưng bạn sẽ hối tiếc.

một số người cần bằng chứng Tôi đã ở trong nhiều tình huống giao dịch với khách hàng hoặc những người khác không đánh giá cao chi phí đảm bảo sự mạnh mẽ và tuân theo các thực tiễn tốt nhất. Tôi sẽ đề nghị bạn tập hợp một số ví dụ về các trường hợp thực tế trong đó chi phí được xác định rõ ràng.