Chiến lược quản lý các gói Oracle mà không vi phạm mã

Question

Tôi tò mò muốn tìm hiểu cách mọi người quản lý các gói của họ trong các ứng dụng của họ.

Ví dụ: trong trường hợp phát triển của chúng tôi, nhà phát triển ứng dụng có thể muốn thay đổi thủ tục được lưu trữ. Tuy nhiên, việc thay đổi thủ tục lưu sẵn sẽ phá vỡ mã Java hiện có cho đến khi lớp DAO được cập nhật để phù hợp với các thay đổi.

Thực tiễn điển hình của tôi là đặt triển khai quy trình mới vào gói "DEV". Sau đó, nhà phát triển có thể thay đổi tham chiếu của mình thành gói này, thực hiện kiểm tra và sau đó khi chúng tôi sẵn sàng, chúng tôi có thể thay thế quy trình trong gói "sản xuất", xóa gói đó khỏi DEV và nhà phát triển thay đổi tham chiếu của mình về gói sản xuất.

Tuy nhiên, tôi thấy nó không hoạt động như bơi lội như tôi muốn. Đầu tiên, nếu có một bó mã Java phụ thuộc vào gói DEV, thì tôi đang ở trong tình huống tương tự như thể đang chỉnh sửa gói sản xuất trực tiếp - nếu tôi phá vỡ gói, tôi sẽ phá vỡ một loạt mã.

Thứ hai, mọi người trở nên bận rộn và chúng tôi không đi xung quanh để chuyển gói hàng này vào sản xuất ngay khi chúng tôi cần. Sau đó, chúng tôi có hai phiên bản của thủ tục lưu trữ trôi nổi xung quanh và nó rất khó để nhớ những gì đã được chuyển vào sản xuất và những gì đã không.

Mục đích là giữ cho các nhà phát triển hoạt động. Vâng, đó là một máy chủ phát triển, nhưng chúng tôi không muốn phá vỡ mã đột ngột.

Có ai có thể đề xuất các phương pháp đã làm việc cho họ để giải quyết vấn đề này không?

Answer 1

Nếu mỗi nhà phát triển có lược đồ riêng trong cơ sở dữ liệu và có các từ đồng nghĩa chung cho tất cả các đối tượng trong lược đồ được chia sẻ và tất cả mã Java sử dụng tên đối tượng không đủ điều kiện, thì bản sao cục bộ của gói trong lược đồ của nhà phát triển cụ thể sẽ được ưu tiên hơn phiên bản được chia sẻ. Vì vậy, nhà phát triển A có thể lấy phiên bản hiện tại của gói, cài đặt nó trong lược đồ cục bộ của mình, thực hiện bất kỳ thay đổi nào cho gói và thực hiện bất kỳ thay đổi Java nào cần thiết trong môi trường phát triển riêng của họ (tôi giả định rằng các nhà phát triển) có máy chủ ứng dụng cục bộ của riêng họ). Khi cả hai bộ thay đổi đủ ổn định, chúng có thể được kiểm tra trong môi trường phát triển chung, cả gói PL/SQL và các thay đổi của Java có thể được xây dựng cho môi trường phát triển được chia sẻ (máy chủ ứng dụng chia sẻ phát triển và lược đồ thực cơ sở dữ liệu phát triển). Sau đó, nhà phát triển có thể thả bản sao gói của họ.

Cách tiếp cận đó hoạt động khá tốt, miễn là các nhà phát triển kiểm tra PL/SQL ngoài kiểm soát nguồn để bắt đầu thay đổi của họ thay vì giả định rằng bất kỳ bản sao cục bộ nào trong lược đồ của họ là hiện tại-- các phiên bản mã xung quanh trong lược đồ cục bộ của chúng, chúng có thể kết thúc với khó khăn để gỡ lỗi các vấn đề mà các phiên bản PL/SQL và Java của chúng không đồng bộ. Bạn có thể giải quyết vấn đề đó bằng cách tự động hóa các quy trình, ví dụ, thả các gói từ các lược đồ nhà phát triển nếu chúng không được sửa đổi trong một khoảng thời gian hợp lý và nếu các gói đó không được kiểm tra bởi nhà phát triển trong điều khiển nguồn hoặc bằng cách xây dựng tập lệnh cho phép nhà phát triển tự động làm mới lược đồ của họ như là một phần của quá trình xây dựng.

Answer 2

Lớp Java/DAO chỉ bị ảnh hưởng nếu đặc tả thủ tục thay đổi (tức là số, tên, vv của tham số). Chiến lược giảm nhẹ cho việc này là

1. Thêm thông số mới với giá trị DEFAULT cho thông số để chúng không cần phải chuyển.
2. Không thay đổi thứ tự các thông số nếu chúng được gọi là vị trí [ví dụ: pkg.proc_a (1,2,3)] hoặc đổi tên chúng nếu được gọi theo tên [ví dụ: pkg.proc_b (p_1 => 1, p_2 => 2)]

3. Sử dụng các gói cho thủ tục và chức năng để bạn có thể quá tải chúng

   tạo hoặc thay thế pkg là proc (p1 trong varchar2); proc (p1 trong varchar2, p2 về số); kết thúc;

Với quá tải bạn có thể có nhiều thủ tục có cùng tên trong một gói chỉ với những con số và/hoặc các kiểu dữ liệu khác nhau của các thông số

11gR2 đã giới thiệu Editioning để giải quyết vấn đề này. Nó cho phép nhiều phiên bản của các gói và mã ứng dụng chọn 'phiên bản' (phiên bản) của mã mà nó muốn xem - phiên bản 'cơ bản' mặc định hoặc một phiên bản phát triển.

Tuy nhiên tôi nghi ngờ việc nâng cấp phiên bản cơ sở dữ liệu không phải là giải pháp thiết thực.