Lý lịch

Tôi đang làm việc trong một nhóm đang tìm cách triển khai các triển khai không thời gian chết. Chúng tôi đang lên kế hoạch sử dụng chiến lược triển khai xanh / xanh để đạt được điều này. Một trong những điều tôi nhận ra khi thực hiện nghiên cứu là mức độ phức tạp của việc thay đổi cơ sở dữ liệu. Một thao tác đơn giản như đổi tên một cột có thể mất 3 chu kỳ phát hành đầy đủ cho đến khi hoàn thành!

Dường như với tôi, việc triển khai đầy đủ thay đổi cần nhiều chu kỳ phát hành mang lại rất nhiều khả năng cho lỗi của con người. Trong bài viết được liên kết, nó cho thấy các thay đổi mã là cần thiết cho 2 bản phát hành và di chuyển cơ sở dữ liệu là cần thiết cho 3 bản phát hành.

Thứ tôi đang tìm kiếm

Hiện tại, nếu chúng ta muốn nhớ làm gì đó, chúng ta có thể tạo một vé trong hệ thống quản lý vấn đề của mình, điều này tạo ra sự lộn xộn và cũng có thể được quản lý chuyển sang chạy nước rút sau hoặc tồn đọng bởi quản lý; hoặc chúng ta có thể tạo một bình luận TODO, có lẽ sẽ bị lãng quên hoàn toàn.

Điều tôi đang tìm kiếm là một cách mà một bình luận TODO có thể có thời hạn cuối cùng và hệ thống Tích hợp liên tục của chúng tôi (hiện tại chưa quyết định mà chúng tôi sẽ sử dụng) sẽ từ chối bản dựng nếu hết thời hạn này.

Ví dụ: nếu chúng tôi đổi tên một cột, chúng tôi có thể tạo di chuyển ban đầu cho cột đó và sau đó hai nhận xét TODO để đảm bảo rằng hai di chuyển còn lại được tạo:

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

Điều này có vẻ khá đơn giản để thực hiện, nhưng tôi tự hỏi nếu một cái gì đó như thế này đã tồn tại, bởi vì tôi không muốn phát minh lại bánh xe.

Suy nghĩ thêm

Tôi cảm thấy mình có thể đang gặp phải vấn đề XY ở đây, vì việc triển khai cuộn và triển khai xanh / xanh được coi là cách thực hành tốt nhất, có vẻ lạ là tôi không thể tìm ra giải pháp giúp cập nhật cơ sở dữ liệu ít đau đớn hơn. Nếu bạn nghĩ rằng tôi đang nhìn vào điều sai hoàn toàn, xin vui lòng cho tôi biết trong một nhận xét! Điều đó nói rằng, ví dụ cơ sở dữ liệu tôi đã đưa ra chỉ là một ví dụ và tôi nghĩ rằng các bình luận TODO có ngày đáo hạn cũng sẽ hữu ích trong các tình huống khác, vì vậy ngay cả khi tôi tiếp cận tình huống cụ thể này, tôi thực sự muốn trả lời câu hỏi thực tế quá. Cảm ơn!

EDIT: Tôi chỉ nghĩ về một tình huống khác mà điều này có thể hữu ích. Nếu bạn sử dụng Kính râm tính năng để bật các phần của ứng dụng khi chúng sẵn sàng, bạn phải cẩn thận để dọn sạch chúng, nếu không bạn có thể kết thúc với Toggle Debt . Bình luận với thời hạn có thể là một cách tốt để ghi nhớ điều này.

Câu hỏi này thực sự là hai câu hỏi trong một.

Bình luận Todo

Trong tất cả các cách để theo dõi các mục hành động, đây là điều tồi tệ nhất. Nhận xét của TODO là tốt trong quá trình làm việc tích cực hoặc như một cách gợi ý cho người bảo trì, "đây là điều có thể được cải thiện trong tương lai". Nhưng nếu bạn dựa vào các nhận xét của TODO để hoàn thành công việc, bạn sẽ thất bại.

Phải làm gì về nó

Nhận xét của TODO về cơ bản là nợ kỹ thuật, vì vậy chúng nên được xử lý như bất kỳ khoản nợ kỹ thuật nào khác. Hoặc giải quyết chúng ngay lập tức, nếu bạn có thời gian, hoặc đưa chúng vào hồ sơ tồn đọng để chúng có thể được theo dõi và ưu tiên.

Nói chung, và điều này hoàn toàn gây tranh cãi và mở cho cuộc tranh luận, các bình luận của TODO có thể được coi là một mùi mã. Nếu một bình luận TODO làm cho nó được kiểm tra phiên bản kiểm soát phiên bản, bạn phải tự hỏi mình, bạn có thực sự sẽ theo dõi nó ngay bây giờ không? Nếu không, điều đó ổn. Chỉ cần thành thật với chính mình và đưa nó vào tồn đọng.

Làm thế nào bạn quản lý tồn đọng này đi vào quá trình kinh doanh, chính trị công ty, và có lẽ một số quyền tự chủ cá nhân. Nhưng bạn vẫn cần tồn đọng theo dõi và ưu tiên để đảm bảo nó xảy ra.

Thay đổi cơ sở dữ liệu

Có, thay đổi cơ sở dữ liệu là khó khăn với chính sách không thời gian chết. Một số thủ thuật để giúp làm giảm bớt đau đớn:

Quá trình hậu triển khai

Tạo một quy trình hậu triển khai chạy như một phần của cùng một bản phát hành. Tuy nhiên, bạn muốn nó làm việc. Trên hệ thống cuối cùng tôi làm việc, tôi đã thiết kế một triển khai 4 pha:

1. kịch bản cơ sở dữ liệu trước
2. ứng dụng web
3. kịch bản cơ sở dữ liệu postapp
4. bảo trì cơ sở dữ liệu kịch bản

Ý tưởng là bất cứ khi nào có thể, chúng tôi sẽ đưa càng nhiều thay đổi cơ sở dữ liệu vào trước càng tốt.

Postapp được dành riêng cho các trường hợp bất thường khi chúng tôi cần thực hiện các thay đổi lược đồ không tương thích. Trong những trường hợp đó, việc áp dụng lại sẽ tạo ra đủ thay đổi để làm cho mã ứng dụng mới tương thích (có thể tạo chế độ xem tạm thời để tương thích) và postapp sẽ dọn sạch mọi tạo phẩm tạm thời như vậy.

Giai đoạn cửa sổ bảo trì được dành riêng cho những thay đổi thực sự cần thời gian chết hoặc khi rủi ro hoặc chi phí triển khai trực tiếp không đáng có. Ví dụ: các tập lệnh thay đổi lượng dữ liệu khổng lồ có thể cần phải khóa toàn bộ bảng.

Triển khai thường xuyên

Nếu bạn triển khai các bản phát hành mới đủ thường xuyên, bạn có thể đạt đến điểm mang thay đổi qua 2 hoặc 3 bản phát hành là chuyện nhỏ. Chu kỳ phát hành dài khuếch đại chi phí thay đổi cơ sở dữ liệu.

Không sử dụng TODO. Bạn đã có một danh sách TODO trong dự án của bạn. Nó được gọi là theo dõi vấn đề.

Tôi nghĩ vấn đề thực sự nằm ở câu này:

chúng ta có thể tạo một vé trong hệ thống quản lý vấn đề của mình, điều này tạo ra sự lộn xộn và cũng có thể được chuyển sang giai đoạn nước rút sau hoặc tồn đọng bởi ban quản lý.

Nếu trình theo dõi vấn đề của bạn tạo ra nhiều lộn xộn, hãy tìm cách khắc phục điều đó. Có thể một loại vấn đề đặc biệt / thẻ liên quan đến lễ ít hơn. Có thể vấn đề phụ. Có lẽ ít lễ hoàn toàn. Chúng tôi thực sự không thể nói. Nhưng nếu trình theo dõi vấn đề của bạn tạo ra quá nhiều công việc, mọi người thay vì đặt ra một câu hỏi phức tạp trên một diễn đàn công cộng hơn là chỉ thêm vấn đề đó, thì có gì đó sai nghiêm trọng.

Nếu quản lý của bạn trì hoãn quá mức phần cuối của một nhiệm vụ, bạn có hai tùy chọn:

1. nói chuyện với quản lý của bạn tại sao đây là một ý tưởng tồi.

2. xử lý nó như là một nhiệm vụ duy nhất. Đây có thể là giải pháp tiêu chuẩn vàng. Trong một thế giới hoàn hảo, bạn sẽ có thể thực hiện ba thay đổi cần thiết trong mỗi bước. Áp dụng một cho nhánh chính, hãy để nó xây dựng và triển khai. Trong khi đó, áp dụng cái thứ hai cho nhánh chính, hãy để nó xây dựng và triển khai và cứ thế để mọi thứ xảy ra trong cùng một lần chạy nước rút, và nếu nó không được thực hiện. Thậm chí có thể một cái gì đó tự động có ý nghĩa khi bạn thực hiện một cách hợp lý một triển khai, nhưng nó thực sự được chia thành 3.

Điều tôi đang tìm kiếm là một cách mà một bình luận TODO có thể có thời hạn cuối cùng và hệ thống Tích hợp liên tục của chúng tôi (hiện tại chưa quyết định mà chúng tôi sẽ sử dụng) sẽ từ chối bản dựng nếu hết thời hạn này.

Những gì bạn yêu cầu là có thể thực hiện được nếu bạn sẵn sàng thực hiện công việc và làm theo.

// TODO by v55: Tạo di chuyển để di chuyển các ràng buộc sang cột mới, xóa tham chiếu đến cột cũ trong ứng dụng // TODO by v56: Tạo di chuyển để thả cột cũ

grep //TODO by v55khi đến lúc triển khai v55. Xây dựng triển khai chạy một kịch bản làm điều đó như một thử nghiệm tích hợp.

Bạn có thể buộc 55 vào theo dõi phiên bản của mình hoặc chỉ cần nhắc cho nó.

Sẽ rất thú vị nếu bạn muốn kiểm tra // TODO bằng v54 khi thực hiện 55. Thay vào đó, hãy tìm kiếm cơ sở mã 55 lần chỉ cần tìm kiếm // TODO theo. Sau đó, lọc kết quả đó từ 1 đến 55. Bây giờ 56 sẽ không gây ra lỗi.

Bạn có thể nghĩ rằng "ồ chúng tôi sẽ không cần điều đó. Chúng tôi sẽ sửa những điều này mỗi lần miễn là chúng tôi có séc". Không, bạn sẽ không.

Chúng tôi đã có một vấn đề rất giống nhau trong nhóm của chúng tôi. Để giải quyết vấn đề này, chúng tôi đã viết một kiểm tra phân tích tĩnh xử lý các TODO này bằng cách kiểm tra vấn đề JIRA hoặc Vấn đề Git mà chúng tham chiếu. Bản dựng của chúng tôi không thành công khi Sự cố được chỉ định di chuyển qua cột "Đang phát triển".

Do đó, chúng tôi có thể thoải mái sử dụng TODO mà không lo chúng bị lãng quên.

Tôi đã tạo ra một triển khai mã nguồn mở này, trong Java. Vâng, một từ chối trách nhiệm là tôi đã viết điều này, nhưng như tôi đã nói nó hoàn toàn mở nguồn và được cấp phép.

Công cụ này được gọi là Westie và một ví dụ về trình kiểm tra vấn đề Jira có trên README.md. Xem thêm GitIssueAnalyser.

Để ngăn tự quảng cáo nếu bạn có thêm bất kỳ câu hỏi nào, hãy gửi cho tôi một tin nhắn. Nếu bạn quyết định sử dụng nó và có bất kỳ đề xuất nào, vui lòng nêu ra bất kỳ vấn đề nào trên github.

Đừng ToDo. Làm ngay bây giờ.

TLDR: Viết (và kiểm tra) các tập lệnh DB của bạn ngay bây giờ, không phải sau này; chỉ cần mã hóa chúng để việc thực thi của chúng phụ thuộc vào phiên bản DB.

Thí dụ

Ví dụ, hãy tưởng tượng rằng bạn muốn thay đổi tên cột từ SSNthành TaxID, một yêu cầu phổ biến khi đi quốc tế.

Để thực hiện điều này, có thể bạn sẽ tạm thời có cả a TaxIDvà một SSNcột. Và trong khi hỗ trợ cả hai phiên bản, bạn sẽ có một kích hoạt để cập nhật cái này từ cái kia. Nhưng bạn không muốn giữ kích hoạt đó vô thời hạn, vì vậy sau này, khi sự tương thích ngược không còn cần thiết nữa, bạn muốn loại bỏ kích hoạt đó (và SSNcột bị bỏ). Chúng tôi sẽ mã hóa tất cả những thứ đó lên phía trước mà không cần bất kỳ vật phẩm ToDo nào.

Trong ví dụ của chúng tôi, chúng tôi sẽ triển khai bản dựng 102 (có cột mới) trong khi vẫn duy trì khả năng tương thích với bản dựng 101 (không có).

Dưới đây là các bước.

1. Thiết lập bảng phiên bản

1. Thêm một bảng duy nhất được gọi Configurationvới hai cột Namevà Value.

2. Thêm một hàng với Name"TargetVersion" và đặt Valuephiên bản của bản dựng mới sẽ được triển khai.

3. Thêm một hàng với một Name"Tương thích với" và đặt Valuesố phiên bản tối thiểu mà việc triển khai phải tương thích.

Kiểm tra và cập nhật các hàng này trước mỗi lần triển khai.

2. Sửa đổi tập lệnh triển khai

1. Thêm một tập lệnh tạo một cột mới TaxID, cạnh nhau SSNvà điền nó từ SSNcột. Gửi mã này trong một Iftuyên bố kiểm tra TargetVersion; nếu phiên bản mục tiêu quá thấp (tức TaxIDlà chưa cần thiết), hãy bỏ qua.

   SELECT @TargetVersion = TargetVersion FROM Configuration
   IF @TargetVersion < '102' THEN RETURN
   ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
   UPDATE Customer SET TaxID = SSN
   

2. Thêm một tập lệnh tạo ra một kích hoạt cư trú TaxIDkhi chèn hoặc cập nhật SSNvà ngược lại. Gửi mã này trong một Iftuyên bố kiểm tra phiên bản đích và phiên bản tương thích; bỏ qua nếu TargetVersion quá thấp ( TaxIDkhông cần thiết) hoặc nếu phiên bản Tương thích quá cao ( SSNtrường không cần thiết).

   SELECT @TargetVersion  = TargetVersion,
          @CompatibleWith = CompatibleWith 
   FROM Configuration
   IF @TargetVersion  < '102' THEN RETURN
   IF @CompatibleWith > '101' THEN RETURN
   CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
   

3. Thêm một tập lệnh để loại bỏ SSNcột. Đính kèm trong một Iftuyên bố loại bỏ cột chỉ khi phiên bản Tương thích đủ cao ( SSNkhông còn cần thiết).

   SELECT @CompatibleWith = CompatibleWith FROM Configuration
   IF @CompatibleWith <= '101' THEN RETURN
   IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
   IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
       ALTER TABLE Customer DROP COLUMN SSN
   END
   

3. Kiểm tra

Hãy chắc chắn kiểm tra việc triển khai của bạn với bất kỳ kết hợp số phiên bản Xanh / Xanh nào mà bạn muốn có thể hỗ trợ trong sản xuất. Bạn có thể kiểm tra ngay khi mã sẵn sàng, bằng cách thao tác Configurationbảng trong môi trường QA của bạn.

4. Trong sổ tay triển khai của bạn

Thêm một bước để một kỹ sư cập nhật phiên bản Tương thích và các hàng TargetVersion. Nếu bạn đang triển khai thành Màu xanh lam, hãy đặt TargetVersion thành số phiên bản của Blue và phiên bản Tương thích với số phiên bản của Green; đảo ngược chúng nếu bạn đang triển khai Green.

Cạm bẫy

Các tập lệnh triển khai của bạn có thể tham chiếu và dựa vào các số phiên bản được giữ trong bảng DB đó. KHÔNG mã thời gian chạy.

Nếu bạn bắt đầu viết mã thời gian chạy để kiểm tra số phiên bản, bạn sẽ đưa ra một mức độ phức tạp mới trong ứng dụng của mình có khả năng trở thành một vấn đề lớn về khả năng bảo trì. Mỗi đường dẫn thực thi thời gian chạy phải được kiểm tra; nếu bạn mang theo những điều kiện này trong tương lai, QA sẽ phải đưa ra một ma trận đau đớn để xác nhận chúng với mỗi bản phát hành. Lời khuyên của tôi là chỉ giữ các điều kiện như thế này trong các kịch bản triển khai.

Kết quả của tất cả điều này

Cuối cùng, bạn sẽ có thể viết tất cả mã lên trước (và cũng kiểm tra nó) mà không sợ rằng nó sẽ được thực thi quá sớm. Ngoài ra, mã sẽ dọn sạch trình kích hoạt tương thích ngược khi thời gian đến mà bạn không cần phải lo lắng về nó nữa.

Bằng cách này, bạn có thể viết và kiểm tra tất cả mã trước, khi bạn nghĩ về nó và bạn không cần phải xử lý những bình luận ToDo lộn xộn đó.

Bạn đang nhận được rất nhiều phản hồi về ý tưởng TODO của bạn, nhưng cá nhân tôi thấy không có vấn đề gì với nó. Cuối cùng, cách tốt nhất (và dễ nhất) để đảm bảo việc di chuyển đi vào sản xuất là bằng cách không thực hiện kiểm tra đơn vị nếu không. Theo nghĩa đen, bạn sẽ mất ít hơn một phút để loại bỏ một chức năng di chuyển trống, ném ra một ngoại lệ nếu phiên bản từ 55 trở lên (hoặc bất cứ yêu cầu nào).

Sau đó, nếu bạn cố gắng phát hành nó, bạn sẽ kết thúc một thử nghiệm thất bại và ai đó sẽ phải biến ngoại lệ đó thành mã di chuyển thực tế.

Không ai có vẻ đang tập trung vào gốc rễ của khiếu nại của mình, đó là thực tế là các thay đổi cơ sở dữ liệu có thể mất quá nhiều chu kỳ phát hành. Anh ấy muốn tiếp tục với lịch triển khai màu xanh / xanh của mình và giải pháp đã có sẵn nhưng trừ khi tôi thiếu một cái gì đó mô tả của anh ấy dường như chỉ ra rằng chỉ có một cơ sở dữ liệu được chia sẻ bởi cả hai hệ thống. Không phải là một hệ thống Blue / Green thực sự nếu đó là trường hợp. Vì có vẻ như cơ sở dữ liệu là cực dài trong lều nên nó cũng được sao chép sao cho dù có mất bao lâu hay bao nhiêu chu kỳ phát hành để thực hiện thay đổi cơ sở dữ liệu trên hệ thống ngoại tuyến, chúng sẽ không hoạt động cho đến khi hoàn thành và kiểm tra đầy đủ. Trong các kịch bản hệ thống ngoại tuyến tạm thời có thể giữ cho cơ sở dữ liệu ngoại tuyến được cập nhật đầy đủ hàng ngày.