055.2 Bài 1

Ổn định là một tính chất trọng yếu mà người dùng mong đợi từ phần mềm. Câu hỏi đầu tiên mà đa số người dùng sẽ đặt ra về một bản phát hành mới là “Nó ổn định đến đâu?” Nói cách khác, nó có thể hoạt động tốt và đáng tin cậy hay sẽ bị sập, làm hỏng dữ liệu hoặc tạo ra các kết quả không chính xác?

Tính ổn định có thể được tính trên một phạm vi rộng, và nhiều người dùng vẫn sẽ vui vẻ sử dụng một phần mềm ngay cả khi nó có lỗi. Tuy nhiên, các nhóm phát triển có xu hướng giữ cho mọi thứ đơn giản và nói theo kiểu nhị phân về các bản phát hành ổn định và không ổn định.

Tính ổn định nói đến cả lỗi của phần mềm lẫn khả năng thay đổi của nó theo cách mà người ngoài có thể nhìn thấy được. Các nhà phát triển có thể coi bản phát hành của một thư viện phần mềm là không ổn định vì họ đã thay đổi các hàm mà lập trình viên gọi (tức là các lập trình viên có thể sẽ phải viết lại phần mềm của họ cho bản phát hành tiếp theo); hoặc phần mềm cũng có thể bị coi là không ổn định theo quan điểm của một người dùng vì các nhà phát triển đã xóa đi một tính năng nào đó.

Vậy có lý do nào cho việc phát hành một phiên bản không ổn định hay không? Có: chúng vẫn có giá trị vì chúng cho phép người dùng dùng thử các tính năng mới và kiểm thử lỗi ngay từ đầu dự án.

Hầu hết các dự án đều phát hành các bản sửa đổi rất sớm của phần mềm cho các khách hàng chủ chốt dùng thử; chúng được gọi là các bản phát hành alpha. Các bản phát hành này không nên được sử dụng cho các công việc thực sự — chúng chỉ nên dành cho việc thử nghiệm. Trên thực tế, kiểm thử viên nên chạy các bản phát hành alpha trên các máy tính đang không thực hiện bất kỳ một công việc quan trọng nào vì lỗi trong các bản phát hành đó thực sự có thể làm hỏng các dữ liệu được lưu trữ trên máy tính.

Khi phần mềm gần như đã được coi là ổn định, dự án thường sẽ phát hành một bản sửa đổi thử nghiệm khác được gọi là bản phát hành beta. Những bản phát hành này vẫn nên chỉ để thử nghiệm chứ không sử dụng cho các công việc sản xuất.

Đối với cả phiên bản alpha và beta, các nhà phát triển đều có một quy trình báo cáo lỗi và theo dõi tiến độ sửa lỗi.

Một số dự án sẽ có thêm một giai đoạn nữa nằm giữa bản beta và các bản phát hành ổn định khi các nhà phát triển đã sửa tất cả các lỗi mà họ có thể và cảm thấy rằng sản phẩm đã được hoàn thiện. Họ gọi phiên bản này là một ứng cử viên phát hành và sẽ trình diện nó cho khách hàng hoặc các bên liên quan chủ chốt để họ có thể lập kế hoạch sử dụng các tính năng mới.

Cuối cùng, một số dự án sẽ đưa vào các tính năng chưa quá ổn định vì có một số người dùng quan trọng yêu cầu. Các nhà phát triển muốn người dùng dùng thử các tính năng này và cho biết họ có thích chúng hay không trước khi các nhà phát triển hoàn thiện giao diện và đầu tư công sức để ổn định các tính năng.

Hầu hết các dự án đều hướng đến tính năng tương thích ngược — nghĩa là họ cố gắng để không phải xóa các tính năng hoặc chức năng đã tồn tại trong các phiên bản cũ. Khả năng tương thích có thể tồn tại ở nhiều cấp độ. Ví dụ: nếu các nhà phát triển duy trì khả năng tương thích ngược cho giao diện lập trình ứng dụng (API) — tức là họ đang hứa hẹn rằng mã nguồn cũ vẫn có thể tiếp tục hoạt động nhưng có thể sẽ cần phải biên dịch lại. Nếu các nhà cung cấp phần cứng hoặc nhà phát triển hệ điều hành duy trì khả năng tương thích ngược cho giao diện ứng dụng nhị phân (ABI) — họ đang hứa hẹn thêm rằng các tệp thực thi cũ vẫn có thể chạy trên các phiên bản phần cứng mới.

Chúng ta sẽ xem xét ở cácphần sau cách các dự án xử lý tình trạng thiếu khả năng tương thích ngược khi họ quyết định rằng giao diện cũ thực sự không phù hợp với các tính năng hoặc môi trường mới mà họ cần hỗ trợ.

Phần mềm sẽ ngày càng tốt và hoàn thiện hơn khi các nhà phát triển khám phá ra các vấn đề và khắc phục chúng. Theo thời gian, nhiều tính năng có thể sẽ ngừng hoạt động do những thay đổi trong môi trường của phần mềm. Ngoài ra, có nhiều lỗi mới bị ẩn trước đây cũng sẽ được phát hiện.

Các phiên bản mới thường kết hợp bảo mật và sửa lỗi với các tính năng mới. Có thể một số người dùng sẽ không cần các tính năng mới (trên thực tế, chúng ta có thể sẽ thích một số các tính năng cũ mà các nhà phát triển đã xóa để nhường chỗ cho các tính năng mới hơn), nhưng mọi người vẫn thường nâng cấp lên phiên bản mới để có được các bản sửa lỗi bảo mật giúp bảo vệ họ khỏi các cuộc tấn công độc hại.

Một số người thực sự vẫn sẽ sử dụng các phiên bản phần mềm cũ và từ chối nâng cấp. Điều này thường là do phiên bản mới làm hỏng thứ gì đó đang hoạt động tốt trong môi trường của họ. Khi các công ty tính phí nâng cấp, một số khách hàng có thể từ chối nâng cấp vì họ không muốn trả thêm tiền. Trên thực tế, việc trả tiền nâng cấp rất hiếm khi xảy ra trong mã nguồn mở.

Các nhà phát triển sẽ hỗ trợ người dùng các phiên bản cũ bằng cách sửa lỗi trong các phiên bản cũ mà không thêm các tính năng làm hỏng phần mềm nếu có thể. Tất nhiên, các nhà phát triển không thể làm điều này mãi mãi vì nó làm tiêu tốn thời gian và năng lượng dành cho công việc mới; sẽ đến lúc họ phải từ chối sửa chữa phiên bản cũ và yêu cầu người dùng nâng cấp hoặc tự sửa lỗi.

Việc sửa lỗi và các lỗ hổng bảo mật được gọi là hỗ trợ cho phần mềm. Điều này khác với việc hỗ trợ do bộ phận trợ giúp và những người khác — những người hướng dẫn người dùng để hiểu về phần mềm — cung cấp. Về mặt quản lý phát hành, một bản phát hành được hỗ trợ là một bản phát hành mà các nhà phát triển đồng ý hỗ trợ sửa lỗi, trong khi một bản phát hành không được hỗ trợ là một bản phát hành mà nhà phát triển từ chối việc sửa chữa.

Hãy lưu ý rằng khái niệm “hỗ trợ” chủ yếu được áp dụng cho phần mềm do các công ty hoặc tổ chức lớn tạo ra. Các dự án mã nguồn mở nhỏ hơn và phụ thuộc nhiều vào các tình nguyện viên thường chỉ có thể hứa hẹn sẽ cố gắng nhất có thể để sửa lỗi và đưa ra các phiên bản mới. Họ không thực sự cảm thấy cần phải sửa các phiên bản cũ. Bởi mã là mã nguồn mở, người dùng không muốn nâng cấp có thể trả tiền cho một người nào đó để họ sửa một phiên bản cũ.

Khi công tác hỗ trợ được triển khai, các nhà phát triển sẽ công bố một lịch trình cho biết họ sẽ hỗ trợ từng phiên bản trong bao lâu. Ngày kết thúc hỗ trợ được gọi là thời hạn kết thúc vòng đời (End of Life - EOL) của phần mềm. Người dùng có thể giữ phiên bản cũ cho đến EOL mà vẫn có thể nhận được sự hỗ trợ về các lỗi; nhưng sau EOL, họ sẽ buộc phải nâng cấp hoặc chấp nhận rủi ro.

Các dự án lớn (chẳng hạn như bản phân phối Debian của GNU/Linux) cung cấp các phiên bản hỗ trợ dài hạn (Long Term Support - LTS). Điều này đơn giản có nghĩa là các nhà phát triển sẽ tiếp tục sửa lỗi trong một số năm nhất định. Những khách hàng coi trọng tính ổn định có thể sẽ cảm thấy lo lắng khi cài đặt các phiên bản phần mềm có nhiều thay đổi trong trường hợp các thay đổi đó làm hỏng các quy trình mà họ tin tưởng. Những khách hàng như vậy, đặc biệt là các tổ chức lớn, thường rất yêu thích tính bảo mật của các phiên bản LTS.

Các nhà phát triển luôn cố gắng đề ra thật sớm những thay đổi mà họ muốn thực hiện đối với một sản phẩm. Trong các công ty thương mại, họ sẽ trao đổi với những người thực hiện công việc tiếp thị để lọc và tóm tắt những gì khách hàng mong muốn. Các dự án mã nguồn mở phụ thuộc nhiều hơn vào các ý tưởng do các nhà phát triển và người dùng gửi; những ý tưởng này được lưu lại trong một cơ sở dữ liệu được gọi là trình theo dõi vấn đề (issue tracker). Nếu cần sửa lỗi hoặc muốn có một tính năng mới, chúng ta sẽ phải điền một bản báo cáo vấn đề (issue). Sau đó, các nhà phát triển sẽ ưu tiên các thay đổi và quyết định xem ai sẽ xử lý thay đổi nào.

Vậy những thay đổi sẽ được lựa chọn và ưu tiên như thế nào? Đây có thể là một quá trình tương đối lộn xộn. Những người quản lý dự án giỏi trong các dự án mã nguồn mở luôn khuyến khích sự đóng góp rộng rãi, song song với đó vẫn đảm bảo sẽ đưa ra các quyết định chính xác. Một số dự án thậm chí còn tổ chức các hội nghị nơi những người tham gia sẽ thảo luận về các ưu tiên.

Một lộ trình (roadmap) được công bố sẽ nêu ra các kế hoạch cải tiến và thay đổi. Nó có thể trải dài suốt nhiều bản phát hành và nhiều năm trong tương lai. Mỗi bước sẽ được gọi là một mốc thời gian; mốc thời gian có thể có hoặc không liên quan đến ngày đích.

Có hai cách cơ bản để lập lịch trình phát hành: theo thời gian và theo tính năng. Một dự án có thể hẹn lịch phát hành theo các khoảng thời gian đều đặn — ví dụ như sáu tháng một lần — và phát hành bất kỳ những gì đã được hoàn thành tại thời điểm đó. Theo cách thứ hai, dự án có thể cam kết một số tính năng nhất định sẽ xuất hiện trong bản phát hành và để các nhà phát triển hoàn thành các tính năng đó trong thời gian mà họ cần.

Khi thời điểm phát hành đến gần, quản lý phát hành sẽ xác định ngày phát hành các bản alpha, beta và bản ổn định. Các thành viên trong nhóm phát triển luôn thường xuyên xem xét các báo cáo lỗi và cố gắng sắp xếp kế hoạch công việc của họ để đạt được các mốc thời gian đó.

Để hoàn thành một bản phát hành, một dự án phải ngừng tiếp nhận ý tưởng về các tính năng mới và tập trung vào việc làm cho các tính năng hiện có hoạt động tốt. Thời điểm này được gọi là phiên đóng băng tính năng (feature freeze).