Quản lý cấu hình và tầm quan trọng

Bài viết của anh  Enoki Ryo- một chuyên viên tư vấn và phát triển hệ thống có kinh nghiệm hơn 10 năm tại một công ty chuyên tư vấn giải pháp CNTT của Nhật Bản (SHIFT)

Bài viết được đăng trên tạp chí công nghệ thông tin Nikkei- TECH  http://tech.nikkeibp.co.jp/

Cho dù đã được cải tiến nhưng chất lượng vẫn đi xuống, nguyên nhân chủ yếu là do việc quản lý cấu hình.

Ở giai đoạn test tích hợp, nếu xuất hiện Degrade chắc chắn Tester hay Dev đều sợ toát hết mồ hôi. Nếu bạn đang nâng cấp version cho phần mềm bằng cách cải tiến lỗi hay thêm chức năng, lúc đó chức năng đang làm việc tự dưng lại không hoạt động nữa. Là hiện tượng chất lượng đi xuống trái ngược với việc version up được gọi là Degrade「デグレ」. Một số trường hợp Degrade khiến phải test lại toàn bộ hệ thống.

Trong một dự án mà anh Enoki Ryo đã từng làm. Degrade xảy ra khi quá trình testing hợp đã qua được một  tuần. Vì đó là Degrade ở chức năng đăng nhập ở giai đoạn đầu của luồng nghiệp vụ, nên các chức năng sau đó đều bj ảnh hưởng. Kết quả các kiểm tra đã làm trong 1 tuần đều phải thực hiện lại. Lúc đó do nhân lực không đủ, nên phải huy động nhân lực của  tất các thành viên của đội dự án.

Ở một dự án khác. Degrade được phát hiện khi release sản phẩm lên môi trường thực tế (production).  Anh Enoki Ryo gặp rắc rối khi thực hiện migrate dữ liệu. Dữ liệu đơn vị teraByte trở thành giá trị dị thường, cuối cùng thì chẳng còn cách nào khác ngoài việc phải trì hoãn việc release lại.  Vụ đó gây phiền phức tới Project member, user, khách hàng của user .. quá nhiều người bị ảnh hướng.

Về nguyên nhân của việc phát sinh Degrade thì có thể  nhiều, nhưng có thể nói là ” việc quản lý version của phần mềm, hay quản lý cấu hình (QLCH) không đầy đủ sẽ dễ phát sinh degrade hơn.”.

Sự bất cập trong quản lý cấu hình sẽ gây ra các vấn đề như [hoạt động trên môi trường test và môi trường phát triển khác nhau]. Trong các dự án mà việc quản lý cấu hình không được duy trì tốt thì thường dev sẽ build 1 bản riêng trên môi trường local sau đấy mới đẩy lên môi trường test. Trong trường hợp này, các môi trường phát triển không nhất quán dẫn đến việc phát hành có thể bị trì hoãn. Có nghĩa là hệ thống đang tồn tại trên môi trường test không phải là phần mềm được giả định ban đầu.

Khi xảy ra degrade, khi mà phát sinh sự khác biệt giữa môi trường test và môi trường phát triển, ít nhất là sẽ phải test lại cho tới thời điểm phát hiện degrate đó. Trường hợp xấu nhất là là phải dừng test và test lại toàn bộ.  Để ngăn ngừa các rắc rối đó, tốt nhất là nên sớm ngăn ngừa từ việc quản lý cấu hình.

Quyết định chính sách trước giai đoạn định nghĩa yêu cầu.

QLCH là việc thực hiện quản lý version của các sản phẩm như tài liệu hoặc chương trình, ghi lại và kiểm tra xem các version nào đang áp dụng cho môi trường test, version nào đang áp dụng cho môi trường production. Có một số  phần mềm quản lý version như 「Subversion」hoặc「Git」

Tuy nhiên, việc QLCH không đơn thuần chỉ là việc giới thiệu công cụ quản lý version, điều quan trọng hơn vẫn là cơ chế và cấu trúc để vận hành QLCH. Project Manager cần phải chỉ định một nhóm chuyên QLCH. Nhóm QLCH sẽ tiến hành quản lý version của phần mềm, quản lý version của mỗi release lên môi trường thực, quản lý version tài liệu dự án từ lúc bắt đầu đến khi kết thúc dự án.

Ở nơi QLCH được duy trì, sẽ quy định luồng vận hành và thể chế để có thể vận dụng việc quán lý chương trình, tài liệu  bằng hệ thống quản lý version. Ví dụ, người QLCH sẽ thực hiện release sản phẩm lên môi trường test đồng thời cập nhật quản lý version cho sản phẩm đó nên sẽ không xảy ra các degrade do khác biệt version nữa.

Hình ảnh trên là so sánh sự khác biệt giữa quản lý cấu hình và ko quản lý cấu hình

Tuy nhiên quản lý cấu hình thường có xu hướng bị trì hoãn . Từ giai đoạn phát triển tới giai đoạn Unit test, ngay cả khi không có QLCH thì cũng khó mà nhận ra điều đó có vấn đề. Do đó, những người liên quan đến dự án sẽ không thấy được tầm quan trọng của việc QLCH. Và tới khi degrade xảy ra ở giai đoạn test kết hợp, lúc đấy những người liên quan mới bắt đầu phải đối mặt với các trouble, họ mới nhận thức được tầm quan trọng của việc QLCH.

QLCH trơn chu không thể thiếu được việc quyết định chính sách từ sớm. Nó phải được quyết định từ giai đoạn định nghĩa yêu cầu. Khi các thành viên đã tạo các thành quả ( program, tài liệu ) mới bắt đầu quyết định chính sách QLCH thì đã là quá muộn. Nếu dự án được bắt đầu mà chưa quyết định chính sách thì các thành viên bắt buộc phải tự  quản lý thành quả của mình một cách độc lập. Khá khó khăn khi thực hiên thu thập tập trung các thành quả đó lại với nhau vì thiếu sự nhất quán. Khi xảy ra vấn đề thì công số để đối ứng cho các vấn đề đó thường rất lớn.

Ước tính sơ bộ thường gây rắc rối

Để ngăn chặn việc QLCH thất bại thì cần có 3 đối sách quan trọng đó là :  (1) Nhận thức về công QLCH , (2) Tổ chức luồng vận hành, (3) Tổ chức về kiến trúc.

Đối sách thứ(1): Nhận thức về công số cho QLCH : là kết quả ở bước estimate thời gian để QLCH.  Mặc dù QLCH có nhiều vai trò, nhưng trong nhiều trường hợp, không có nguồn nhân lực tương ứng với nó. Ước tính thô thường có xu hướng xa rời mốc estimate và dẫn đến việc không đủ thời gian để thực hiện. Và khi nhân công và budget không đủ, thì việc QLCH không được thực hiện đầy đủ hoặc sẽ bị trì hoãn.

QLCH khác với việc phát triển, nó không tạo ra các thành quả trực tiếp.  Nó đóng một vai trò bổ sung để hỗ trợ dự án. Vì lý do đó, nhiều nhà quản lý dự án đưa ra các ước tính như “Công quản lý sẽ chiếm bao nhiêu % so với công đối ứng của cả dự án hoặc bao nhiêu % so với  việc tạo ra sản phẩm”. Với một ước tính sơ bộ như vậy, vai trò và công việc cụ thể của quản lý cấu hình không được làm rõ.

Như đã đề cập ở trên, QLCH là một vấn đề phải được quyết định ở giai đoạn ban đầu. Cho dù điều này được thực hiện hay không nó cũng sẽ ảnh hưởng đến chất lượng của các sản phẩm. Vì vậy, cần phải xác định task vụ (QLCH)  sau đó estimate cho các task vụ đó.

Sau đây là một số task vụ mà anh Enoki Ryo đã từng có cơ hội tham gia ở một số dự án trong quá khứ.

▼Ở giai đoạn định nghĩa yêu cầu

・Chính sách quản lý cấu hình

・Sắp xếp luồng vận hành

・Lựa chọn quản lý cấu hình và công cụ quản lý dự án để sử dụng.

▼Ở giai đoạn thiết kế cơ bản

・Giới thiệu công cụ

・Sắp xếp thứ tự các task vụ

・Tổ chức kế hoạch dự phòng (đối ứng khi release thất bại..)

▼Ở giai đoạn phát triển và unit test.

・Triển khai các nguyên tắc quản lý cấu hình và công cụ build đến developer.

・Quản lý version cho từng milestone và triển khai môi trường buil hàng ngày .

▼Ở giai đoạn test tích hợp

・Thiết lập ban đầu ở mỗi môi trường test tích hợp ( phát hành các sản phẩm được quản lý version ）

・Quản lý các vấn đề  liên quan đến bug, hoặc thay đổi spect.

・Quản lý đơn xin chấp thuận của từng nhóm kèm với quản lý các vấn đề phát sinh của nó

・Quản lý yêu cầu release

・Chấp nhận và thực hiện release.

Sau khi xác định các task vụ trên, sẽ có cơ sở rõ ràng để estimate chính xác được.  Nếu phân bổ đúng nhân sự và thời gian QLCH, thì sẽ giảm được các trouble phát sinh, do đó có thể giảm được công của toàn bộ dự án.

Tất nhiên tùy từng dự án thì những task vụ cần làm là khác nhau do đó cần phải tham khảo kinh nghiệm của các chuyên gia.

Tổ chức luồng vận hành để tránh việc phụ thuộc vào con người

Đối sách thứ(2): Việc tổ chức lại luồng vận hành , với mục đích để  ai cũng có thể QLCH mà không ảnh hưởng tới chất lượng sản phẩm.

Các task vụ của QLCH càng nhiều, khi các task vụ đó bị trì hoãn, sẽ dẫn tới ảnh hưởng đến tiến độ của toàn bộ dự án , của team phát triển và team test.  

Quá trình tổ chức lại đó phát sinh 2 vấn đề. (1) Đối với các team khác ngoài team quản lý cấu hình, trạng thái  QLCH trở thành vô hình. (2) Việc chuyển giao /tiếp nhận các task vụ sẽ trở nên khó khăn.

Việc trạng thái QLCH vô hình với các đội khác, sẽ phát sinh nhiều vấn đề khác nhau. Ví dụ, khi nhóm phát triển muốn release sản phẩm, họ cũng chẳng biết nên gửi đơn yêu cầu cho ai, và như thế nào. Ngay cả khi đơn yêu cầu release được gửi,  nội dung yêu cầu không được mô tả đầy đủ sẽ khiến cho nhóm QLCH lúng túng, khiến cho việc release không được như kế hoạch ban đầu. Với tình trạng đó, thì cũng sẽ ảnh hưởng tới kế hoạch test của team kiểm thử.

Việc chuyển giao /tiếp nhận các task vụ trở nên khó khăn là lúc mà nghiệp vụ QLCH được thực hiện bởi 1 người duy nhất, và khi người đó nghỉ thì không có người thay thế dẫn đến việc release hay quản lý sản phẩm sẽ gặp rắc rồi thậm chí bị dừng.

Để ngăn tình trạng, thiết lập luồng vận hành QLCH đối với từng dự án. Luồng vận hành không được thiết lập cùng một lúc, nhưng thường xuyên được đánh giá với từng dự án. Các kết quả đánh giá được chia sẻ trong suốt dự án. Nên tạo tài liệu và trainning để tất cả các thành viên dự án hiểu rõ luồng vận hành. Trong dự án, nếu luồng vận hành thay đổi, phải giải thích và xác nhận lại ý đồ của luồng vận hành cho các thành viên của đội dự án.

Dưới đây là ví dụ về luồng vận hành QLCH của dự án.

Hình ảnh trên là ví dụ về luồng vận hành của quản lý cấu hình

Luồng vận hành này sẽ thực hiện QLCH theo 6 bước

1. Lập trình viên sẽ tạo yêu cầu, người QLCH sẽ lấy program từ SVN QLCH ( SVN dùng cho môi trường thực) và trao nó cho lập trình viên.
2. Lập trình viên commit lên SVN của team mình, và thực hiện phát triển. Bằng việc build hàng ngày sẽ phát hiện sớm nhưng Degrade giữa các nhóm.
3. Sau khi việc phát triển được hoàn thành, người có trách nhiệm của nhóm phát triển chấp nhận và phát hành ứng dụng cho nhóm quản lý cấu hình
4. Nhóm QLCH sẽ release lên môi trường test tích hợp
5. Nhóm QLCH  sẽ thực hiện commit chương trình lên  SVN QLCH tại thời điểm đó.
6. Từ SVN QLCH, sẽ thực hiện release lên môi trường thật.

Luồng vận hành sẽ được người QLCH quyết định trước mỗi phase phát triển. Như đã nói ở trên, tất cả các thành viên của đội dự án sẽ phải nắm bắt được luồng vận hành QLCH chứ không chỉ người QLCH. Cần xác định luồng vận hành của phase tiếp theo khi kết thúc phase hiện tại và coi đó là một điều kiện tiên quyết để có thể kết thúc 1 phase.

Việc xây dựng luồng vận hành cho mỗi dự án và mỗi giai đoạn từ đầu khá là tốn kém, do vậy cần cân nhắc sử dụng các luồng vận hành từ kinh nghiệm của các dự án trong quá khứ, tất nhiên không phải áp đặt giống hoàn toàn mà sẽ có những thay đổi cho phù hợp với công nghệ, phương pháp phát triển, mô hình phát triển của từng dự án.

Tham gia tích cực vào việc đánh giá nghiên cứu kiến trúc

Đối sách thứ(3): Tổ chức kiến trúc, hãy áp dụng kiến trúc để dễ dàng QLCH. Người QLCH tham gia vào team nghiên cứu hiểu kiến trúc. Ví dụ, thứ tự release sẽ khác nhau tuỳ từng loại kiến trúc. Nếu kiến trúc này không phù hợp với phương pháp phát triển hay thể chế phát triển thì có thể sẽ mất nhiều thời gian để release hơn hoặc nhiều nỗ lực hơn mức cần thiết.

Trong những năm gần đây, việc áp dụng mã nguồn mở (OSS) trong các hệ thống lớn ngày càng tăng, tầm quan trọng của việc tổ chức kiến trúc cũng gia tăng. Mặc dù OSS giúp giảm thiểu chi phí và rút ngắn thời gian của dự án nhưng ít người có thể hiểu được cấu trúc nội bộ của OSS một các chi tiết. Do vậy nhiều trường hợp nhóm đánh giá nghiên cứu kiến trúc đã phát triển một framework độc lập và nhúng (dấu ) OSS vào đó.

Khi phát triển một framework độc lập như vậy, việc cân nhắc QLCH thường có xu hướng bị bỏ xót. Mặc dù thành viên của đội nghiên cứu kiến trúc là những nhà chuyên môn về kỹ thuật, nhưng không thể biết được hết độ phức tạp của QLCH của việc phát triển hệ thống quy mô lớn. Do vậy, người đảm nhiệm QLCH nên tham gia vào việc nghiên cứu kiến trúc.

Giả sử áp dụng một kiến trúc sử dụng các thư viện dùng chung. Một kiến trúc như vậy, việc phân phối thư viện dùng chung cho các lập trình viên sẽ trở thành vấn đề. Mặc dù việc sử dụng công cụ cài đặt tự động thư viện như Maven khá là hiệu quả, nhưng ngay từ giai đoạn phát triển ban đầu cần phải xây dựng một Repository(nguồn) chia sẻ. Nếu không có sự hợp tác giữa Team QLCH và team kiến trúc thì khó có thể xây dựng được một cơ chế như vậy ngay từ giai đoạn phát triển bản đầu.

Việc áp dụng kiến trúc phụ thuộc vào thư việc trong IDE (môi trường phát triển tích hợp ) cũng cần được cân nhắc cẩn thận cho dù nó tiện cho việc tích hợp OSS. Bởi vì nhóm QLCH thường xuyên phải build một khối lượng lớn các chương trình cùng một lúc nên thay vì sử dụng IDE thì họ thường dùng Makefile hay Shell hoặc Batchcode. Có những tình huống mà kết quả build của lập trình viên bằng IDE khác với kết quả build của team QLCH. Khi yêu cầu team QLCH build bằng IDE thì mỗi lần release phải mất đến cả ngày.

Điều quan trọng đó là người QLCH hiểu được kiến trúc, và biết được các thông tin cần thiết để build hay release. Tuỳ từng trường hợp thảo luận các thay đổi kiến trúc cho phù hợp và dễ thực hiện quản lý cấu hình. Việc thay đổi kiến trúc khi bước vào giai đoạn test tích hợp là không thể. Nên team QLCH cần tham gia từ giai đoạn nghiên cứu.

Như anh Enoki Ryo đã giải thích, việc quản lý cấu hình là một quá trình quan trọng đóng góp vai trò là nền tảng của dự án phát triển phần mềm. Nhưng hiện nay các nhà phát triển hoặc các nhóm nhỏ có xu hướng bắt đầu dự án mà thiếu sự chuẩn bị. vì vây anh Enoki Ryo hi vọng rằng mọi người có thể tham khảo 3 điểm mà anh đã chia sẻ để thực hành QLCH để đảm bảo tiến độ của dự án.

(Sưu tầm và dịch)