Bản vá phần mềm là gì?

What is a software patch?

By Ross Gardler, Published: 07 January 2008, Reviewed: 09 July 2012

Theo: http://www.oss-watch.ac.uk/resources/softwarepatch

Bài được đưa lên Internet ngày: 09/07/2012

Lời người dịch: Bản vá là gì và vì sao bản vá là siêu quan trọng trong một dự án phát triển mở. Bài viết này phân tích chi tiết việc những người đóng góp cho dự án tạo ra các bản vá như là một tính năng mới hoặc một sửa lỗi rồi đóng góp lại cho cộng đồng dự án thông qua những người duy trì kho mã nguồn của dự án và mối quan hệ tương hỗ giữa họ, và cả những khuyến cáo để sao cho các bản vá mà bạn đóng góp vào dễ được áp dụng trong các phiên bản sẽ được phát hành trong tương lai của phần mềm nguồn mở trong dự án đó, đặc biệt là phương châm “Phát hành sớm, phát hành thường xuyên” có liên quan thế nào tới việc tạo ra và đề xuất các bản vá của dự án.

Một bản vá là một hồ sơ những thay đổi được làm thành một tập hợp các tài nguyên. Thường thì một bản vá sẽ bổ sung thêm một tính năng mới, sửa một lỗi hoặc bổ sung thêm tài liệu cho dự án. Ý nghĩa phổ biến của việc tạo ra một bản vá là bằng việc sử dụng diff, một công cụ có sẵn phổ biến trong các hệ thống Linux và Unix.

Các bản vá là cách thức được ưu tiên để đệ trình những đóng góp cho các dự án phát triển mở như phần mềm nguồn mở (PMNM). Người đóng góp tạo ra một bản vá và đệ trình nó cho dự án. Người duy trì dự án có thể sau đó kiểm tra những thay đổi và áp dụng chúng cho kho mã chính nếu họ chọn thế. Các công cụ khác nhau là sẵn sàng để giúp với các bản vá. Những công cụ đó làm cho rất dễ dàng để tạo và quản lý các bản vá cho các đầu ra của dự án như mã nguồn và tài liệu. Các bản vá và các công cụ quản lý bản vá là chìa khóa cho việc xây dựng một cộng đồng tích cực những người đóng góp cho một dự án phát triển mở.

Tài liệu này đưa ra một tổng quan đơn giản về một bản vá phần mềm. Nó không làm viecj với các cơ chế tạo ra và xử lý các bản vá, những thứ sẽ được điều khiển tốt hơn bằng tài liệu của công cụ quản lý bản vá được lựa chọn. Trong phần tiếp theo, chúng tôi liệt kê vài công cụ để giúp bạn làm quen với việc tạo ra các bản vá.

Tạo một bản vá

Khi một người đóng góp thực hiện một thay đổi cho các đầu ra của một dự án, họ làm thế bằng việc soạn sửa các tập có sẵn trong một hệ thống kiểm soát phiên bản. Hệ thống kiểm soát phiên bản theo dõi các thay đổi đối với các tài liệu và mã nguồn theo thời gian. Việc sử dụng một hệ thống kiểm soát phiên bản để tiến hành tạo ra một bản vá là đơn giản vì bạn luôn có thể tham chiếu tới phiên bản của mã nguồn mà những thay đổi đó dựa vào. Tuy nhiên, có một vài bước nên được thực hiện để tối đa hóa những cơ hội để bản vá được những người duy trì dự án chấp nhận.

Điều quan trọng là người đóng góp đảm bảo rằng bản vá tuân thủ với bất kỳ tài liệu và các tiêu chuẩn viết mã nào mà dự án áp dụng. Cũng là sống còn để kiểm tra kỹ những thay đổi đối với các bộ kiểm thử nào mà dự án cung cấp. Cuối cùng, mỗi đóng góp nên được làm thành tài liệu một cách rõ ràng, tối thiểu là với các chi tiết về:

• nó định làm gì

• nó định triển khai như thế nào

• nó được sử dụng như thế nào

Một khi người đóng góp thỏa mãn rằng bản vá đáng để những người duy trì dự án xem xét, thì bản vá phải được tạo ra.

Việc người đóng góp làm thế nào tạo ra được bản vá là phụ thuộc vào môi trường phát triển nào họ đang sử dụng và trong hệ thống kiểm soát phiên bản nào dự án đang sử dụng. Hầu hết các môi trường phát triển tích hợp - IDE (Integrated Development Environment) bao gồm một tính năng để tạo một bản vá. Cũng có nhiều công cụ bạn có thể cài đặt, cung cấp các giao diện dòng lệnh hoặc GUI cho các công cụ tạo bản vá.

Sau khi chạy công cụ được chọn, một hoặc nhiều tệp sẽ được tạo ra. Nói chung, các tệp đó mô tả những thay đổi được thực hiện trong đóng góp đó. Thường thì nhiều tệp sẽ được đặt vào một tệp lưu trữ duy nhất để dễ quản lý. Lưu trữ này được gọi là một bản vá. Đây chính là bản vá mà một người đóng góp đệ trình cho dự án.

Qui trình đệ trình thực sự khác nhau đối với từng dự án, nhưng trong tất cả các trường hợp sẽ có một yêu cầu đề cập tới sự chỉ định bản quyền hoặc các quyền sử dụng sở hữu trí tuệ (IP) nằm bên trong bản vá đó. Điều này được thảo luận xa hơn trong Thỏa thuận Giấy phép của Người đóng góp.

Áp dụng một bản vá

Một khi một bản vá đã được một người đóng góp đệ trình, thì sau đó trách nhiệm của những người duy trì dự án để đánh giá và, ở những nơi phù hợp, áp dụng bản vá đó. Các dự án khác nhau có các tiếp cận về việc rà soát lại và áp dụng các bản vá khác nhau. Tuy nhiên, chúng tất cả có vài bước chung như sau:

• nhanh chóng đánh giá giá trị của bản vá

• chuẩn bị nhắc nhở và ý kiến phản hồi xác đáng cho người đóng góp (yêu cầu một đề xuất lại ở những nơi phù hợp)

• thử áp dụng bản vá

• chạy bất kỳ bộ kiểm thử nào đối với mã được thay đổi

• báo cáo bất kỳ vấn đề gì cho người đóng góp và yêu cầu đề xuất lại

• đệ trình bản vá cho hệ thống kiểm soát phiên bản

Các lập trình viên có kỹ năng có thể đọc các tệp bản vá và hiểu những tác động của chúng mà thực sự không cần áp dụng chúng cho kho mã. Điều này làm cho dễ dàng để đưa ra ý kiến phản hồi nhanh cho người đóng góp. Nếu người duy trì dự án sẽ cảm thấy rằng bản vá trông giống như một sự đóng góp cứng cáp, thì họ sẽ áp dụng nó cho bản sao phát triển cục bộ của họ và kiểm thử nó. Vì một đóng góp tốt sẽ luôn trải qua việc kiểm thử mở rộng, điều này sẽ là một vấn đề đơn giản cho người duy trì. Tuy nhiên, các sai sót có thể được thực hiện và vì thế việc kiểm thử tiếp nên luôn được triển khai.

Một khi một bản vá sẵn sàng để được áp dụng cho cây kiểm soát phiên bản, thì người duy trì sẽ 'đệ trình' (commit) nó. Đó là, họ sẽ làm cho nó sẵn sàng trong hệ thống kiểm soát phiên bản công khai. Hành động này thường sẽ tạo ra một thông báo tự động cho cộng đồng các lập trình viên thông qua một danh sách thư 'đệ trình'. Tại thời điểm này, cộng đồng rộng lớn hơn được trao cơ hội để rà soát lại sự đóng góp đó; nếu thay đổi đó là trong câu trả lời cho một báo cáo lỗi hoặc một yêu cầu tính năng, thì một phiếu (ticket) có liên quan trong trình theo dõi vấn đề sẽ được cập nhật.

Liệu điều này có thực sự là đơn giản?

Để mọi điều làm việc được trơn tru như được mô tả ở trên, điều quan trọng là những người đóng góp tạo ra các bản vá đối với một phiên bản gần đây của các đầu ra của dự án (thường là mã của phần mềm), ưu tiên phiên bản gần đây nhất, từ 'đầu' của hệ thống kiểm soát phiên bản. Điều này là vì, khi thời gian trôi đi, mã sẽ tiến hóa. Nếu mã theo yêu cầu đã thay đổi kể từ khi người đóng góp đã tải về bản sao của chúng, thì việc áp dụng bản vá đó có thể không đơn giản như được mô tả ở trên, vì có thể có những xung đột đối với những thay đổi.

Vì những người sử dụng thường muốn làm việc với một phiên bản mã ổn định trong một môi trường sản xuất, có khả năng là những thay đổi ban đầu còn chưa được thực hiện đối với phiên bản phát triển phần mềm mới nhất. Điều này tạo ra một sự khó xử cho người đóng góp: họ đóng góp một bản vá đối với một phiên bản cũ của mã, hay họ đầu tư thời gian vào việc tạo ra một bản vá đối với phiên bản phát triển mới nhất?

Để tối đa hóa những cơ hội của một bản vá được chấp nhận, người đóng góp nên đệ trình bản vá đối với phiên bản phát triển mới nhất. Vì thế người đóng góp nên có một bản sao của sự phát triển của dự án được triển khai và sẵn sàng để kiểm thử. Tất cả những đóng góp trước hết nên được áp dụng cho phiên bản phát triển này, và bất kỳ sự thay đổi nào tiếp sau cần thiết phải đảm bảo nó làm việc được như mong đợi sẽ được thực hiện.

Việc có một môi trường phát triển được triển khai như thế này đã bổ sung thêm lợi ích của việc cho phép tổ chức kiểm thử phiên bản phát triển hiện hành trong một môi trường không sống còn. Điều này tới lượt nó sẽ giúp cho quyết định để nâng cấp hay không khi một phát hành mới là sẵn sàng.

Sự thất bại của những người đóng góp để tạo ra các bản vá đối với phiên bản phát triển mới nhất của dự án sẽ làm gia tăng số lượng thời gian mà một người duy trì cần phải đầu tư vào trong việc rà soát lại và áp dụng bản vá. Hệ quả là, những cơ hội được chấp nhận của nó bị giảm thiểu đáng kể. sự từ chối sẽ không ngăn cản được tổ chức của người đóng góp khỏi việc sử dụng bản vá, nhưng nó sẽ có nghĩa là một nâng cấp tới các phiên bản trong tương lai sẽ được thực hiện phức tạp hơn, vì những sửa đổi cục bộ của họ sẽ phải được áp dụng lại cho các phiên bản mới. Hệ quả là, việc đặt nỗ lực vào ở một giai đoạn sớm sẽ làm giảm nỗ lực để nâng cấp và vì thế làm cho có nhiều khả năng hơn là một bản nâng cấp sẽ chạy được trơn tru.

Thậm chí dù được khuyến caó cho những người đóng góp để làm việc đối với các nguồn phát triển mới nhất, các dự án vẫn nên có thiện chí cân nhắc các bản vá đối với các phiên bản cũ. Một bản vá đối với một phiên bản cũ là tốt hơn so với không có bản vá nào cả. Liệu một bản vá như vậy có được áp dụng hay không, phụ thuộc vào cộng đồng và vào giá trị được thừa nhận của bản vá đó. Một sự bổ sung thêm tính năng hoặc một sửa lỗi quan trọng có khả năng sẽ được áp dụng, trong khi một tính năng phù hợp có thể bị bỏ qua khi mà có thể không có các lập trình viên tích cực nào với một nhu cầu cho tính năng đó.

Phát hành sớm, phát hành thường xuyên

Để giảm thiểu những cơ hội của người sử dụng đệ trình các bản vá đối với một phiên bản đã lỗi thời, các dự án phát triển mở nên phát hành sớm và phát hành thường xuyên. Trong các giai đoạn sớm của một dự án, các phiên bản của dự án càng thường xuyên bao nhiều, thì con đường nâng cấp càng dễ dàng hơn bấy nhiêu, người sử dụng có khả năng sẽ chuyển sang một phiên bản mới nhiều hơn. Hệ quả là, họ có khả năng nhiều hơn cung cấp các bản vá đối với một kho mã gần đây hơn. Việc chăm sóc những người sử dụng theo cách này đảm bảo rằng dự án giúp cho những người sử dụng trở thành những người đóng góp có giá trị với nỗ lực nhỏ nhất.

Một dự án có càng nhiều người đóng góp, thì có khả năng nhiều hơn là nó sẽ sống sót. Đối với các dự án nguồn mở, việc xây dựng và duy trì một cộng đồng tích cực là sống còn cho sự bền vững.

Vì sao tôi nên đóng góp một bản vá?

Một số người hoài nghi vì sao họ nên đặt nỗ lực vào việc cung cấp một bản vá. Họ có thể coi nó là công việc bổ sung hơn và trên các nỗ lực phát triển của việc tạo ra những sửa đổi trước tiên. Tuy nhiên, thuần túy có lợi ích ích kỷ trong việc tạo ra và đệ trình một bản vá có chất lượng: nó làm cho dễ dàng hơn để duy trì sự sử dụng của bạn đối với các đầu ra của dự án.

Tại một số thời điểm trong tương lai, một tổ chức có khả năng muốn sử dụng phiên bản mới nhất và tốt nhất các đầu ra của dự án. Nếu nhân viên của tổ chức đó thất bại để làm việc với cộng đồng để có những sửa đổi cục bộ của họ được chấp nhận, chì họ sẽ cần phải áp dụng lại tất cả các thay đổi, hoặc đánh mất chúng. Đó là, tổ chức sẽ trả tiền cho nhân viên của mình để thực hiện mỗi sự thay đổi 2 lần.

Dễ dàng để bỏ qua thực tế này. Sau tất cả, mỗi thay đổi dường như là đáng kể và dễ dàng để áp dụng lại. tuy nhiên, mỗi thay đổi là tích cóp dồn lại, và vì dự án từng đã và đang có tiến bộ một cách độc lập với những thay đổi của bạn, hoàn toàn có thể rằng ứng dụng các sửa đổi của bạn sẽ không còn là một hoạt động đơn giản nữa.

Việc đệ trình một bản vá cho một dự án không đảm bảo rằng nó sẽ được đưa vào, mà nó chắc chắn làm gia tăng các cơ hội, đặc biệt nếu nhân viên được khuyến khích để làm việc với những người duy trì dự án để đảm bảo bản vá là tương thích với các mục tiêu của dự án. Là hiếm đối với các dự án để từ chối hoàn toàn các bản vá; bất kỳ sự từ chối nào cũng thường đi với những khuyến cáo cho các cách thức để làm cho nó áp dụng được đối với cộng đồng.

Cuối cùng, hành động cung cấp các bản vá cho các dự án đảm bảo rằng một tổ chức có một con đường nâng cấp rẻ hơn và nó làm cho dễ dàng hơn để tạo ra các phiên bản. Cùng lúc, chúng giúp để đảm bảo rằng phần mềm mà họ phụ thuộc vào vẫn giữ được trong sự phát triển tích cực. Mark Johnson đã chỉ ra trong bài trình bày của ông tại TransferSummit/UK 2010 cách mà nó có thể đáng làm để cung cấp các bản vá và trở nên tích cực trong một dự án phát triển mở. Vì thế, đây là một cách tuyệt vời để giúp xây dựng cộng đồng xung quanh dự án của bạn.

A patch is a record of changes made to a set of resources. Typically a patch will add a new feature, fix a bug, or add documentation to the project. A popular means of creating a patch is by using diff, a tool that is commonly available on Linux and Unix systems.

Patches are the preferred way to submit contributions to open development projects such as open source software. The contributor cre-ates a patch and submits it to the project. The project maintainer can then inspect the changes and apply them to the main code base if they so choose. Various tools are available to help with patches. These tools make it very easy to cre-ate and manage patches for project outputs such as source code and documentation. Patches and patch management tools are the key to building an active community of contributors to an open development project.

This document provides a simple overview of a software patch. It does not deal with the mechanics of creating and processing patches, which are better handled by the documentation of the patch management tool chosen. In the further reading section, we list a few tools to help you get started with creating patches.

Creating a patch

When a contributor makes a change to the outputs of a project they do so by editing files available in a version control system. A version control system tracks changes to documents and source code over time. Using one makes creating a patch simple because you can always refer to the version of the source code the changes are based upon. However, there are a few steps that should be taken to maximise the chances of the patch being accepted by the maintainers of a project.

It is important that the contributor ensures that the patch complies with any documentation and coding standards adopted by the project. It is also critical to thoroughly test changes against any test suites the project provides. Finally, each contribution should be clearly documented with, at a minimum, details on:

• what it is intended to do

• how it is implemented

• how it is used

Once the contributor is satisfied that the patch is worthy of consideration by the project maintainers, a patch must be cre-ated.

How the contributor cre-ates the patch depends on which development environment they are using and on which version control system the project is using. Most Integrated Development Environments (IDEs) include a feature to generate a patch. There are also many tools you can install, providing command line or GUI interfaces to patch generation tools.

After running the chosen tool, one or more files will be produced. Collectively, these files describe the changes made in the contribution. Often multiple files will be placed into a single archive file for ease of management. This archive is called a patch. It is this patch that a contributor submits to the project.

The actual submission process varies f-rom project to project, but in all cases there will be a requirement to address the assignment of copyright or rights to use the IP contained within the patch. This is discussed further in Contributor Licence Agreements.

Applying a patch

Once a patch has been submitted by a contributor, it is then the responsibility of the project maintainers to evaluate and, whe-re appropriate, apply the patch. Different projects have different approaches to reviewing and applying patches. However, they all have some common steps:

• quickly evaluate the value of the patch

• prepare prompt and accurate feedback to the contributor (requesting a resubmission whe-re appropriate)

• experimentally apply the patch

• run any test suites against changed code

• report any problems to the contributor and request a resubmission

• commit the patch to the version control system

Skilled developers can read patch files and understand their implications without actually applying them to the code base. This makes it easy to provide rapid feedback to the contributor. Should the project maintainer feel that the patch looks like a solid contribution, they will apply it to their local development copy and test it. Since a good contribution will already have undergone extensive testing, this should be a simple matter for the maintainer. However, mistakes can be made and so further testing should always be carried out.

Once a patch is ready to be applied to the version control tree, the maintainer will ‘commit’ it. That is, they will make it available in the public version control system. This action will usually result in an automated notification to the developer community via a ‘commit’ email list. At this point, the wider community is given the opportunity to review the contribution; if the change is in response to a bug report or a feature request, the associated ticket in the issue tracker should be up-dated.

Is it really that simple?

For things to work as smoothly as described above, it is important that contributors cre-ate patches against a recent version of the project outputs (usually software code), preferably the most recent version, f-rom the ‘head’ of the version control system. This is because, as time passes, code will evolve. If the code in question has changed since the contributor downloaded their copy, applying the patch may not be as simple as described above, since there may be conflicting changes.

Since users often want to work with a stable version of the code in a production environment, it is possible that the initial changes were not made against the latest development version of software. This cre-ates a dilemma for the contributor: do they contribute a patch against an old version of the code, or do they invest the time in creating a patch against the latest development version?

In order to maximise the chances of a patch being accepted, the contributor should submit the patch against the latest development version. Therefore the contributor should have a development copy of the project deployed and ready to test against. All contributions should first be applied to this development version, and any further changes necessary to ensure it works as expected should be made.

Having a development environment deployed like this has the added benefit of allowing the organisation to test current development versions in a non-critical environment. This, in turn, helps with the decision to upgrade or not when a new release is available.

Failure of contributors to cre-ate patches against the latest development version of a project will increase the amount of time a maintainer needs to invest in reviewing and applying the patch. Consequently, the chances of its being accepted are significantly reduced. Rejection will not prevent the contributor’s organisation f-rom using the patch, but it will mean that an upgrade to future releases is made more complicated, since their local modifications will have to be reapplied to new releases. Consequently, putting the effort in at an early stage will reduce the effort to upgrade and thus make it more likely that an upgrade will go smoothly.

Even though it is advisable for contributors to work against the latest development resources, projects should still be willing to consider patches against older versions. A patch against an old version is better than no patch at all. Whether such a patch is applied or not depends on the community and on the perceived value of the patch. An important feature addition or a bug fix is likely to be applied, whe-reas a niche feature may be ignored as there may be no active developers with a need for that feature.

Release early, release often

To minimise the chances of users submitting patches against an outdated release, open development projects should release early and release often. In teh early stages of a project, the more frequent the project releases are, and the easier the upgrade path, the more likely users are to move to a new version. Consequently, they are more likely to provide patches against a more recent code base. Looking after users in this way ensures that the project enables users to become valuable contributors with minimal effort.

The more contributors a project has, the more likely it is to survive. For open source projects, building and maintaining an active community are vital for sustainability.

Why should I contribute a patch?

Some people wonder why they should put the effort into providing a patch. They may consider it additional work over and above the development effort of making the modifications in the first place. However, there is purely selfish benefit in creating and submitting a quality patch: it makes it easier to maintain your use of the project outputs.

At some point in the future an organisation is likely to want to use the latest and greatest release of the project outputs. If that organisation’s staff has failed to work with the community in order to have their local modifications accepted, they will need to reapply all changes, or lose them. That is, the organisation will be paying its staff to make each change twice.

It is easy to ignore this fact. After all, each change seems insignificant and easy to reapply. However, each change is cumulative, and since the project has been progressing independently of your changes, it is quite possible that the application of your modifications will no longer be a simple activity.

Submitting a patch to a project does not guarantee that it will be included, but it certainly increases the chances, especially if staff are encouraged to work with project maintainers to ensure the patch is compatible with the objectives of the project. It is rare for projects to refuse patches outright; any refusal is usually accompanied by recommendations for ways to make it acceptable to the community.

Ultimately, the act of providing patches to projects ensures that an organisation has a cheaper upgrade path and it makes it easier to cre-ate releases. At the same time, they help to ensure that the software they depend on remains in active development. Mark Johnson showed in his presentation at TransferSummit/UK 2010 how rewarding it can be to provide patches and become active in an open development project. As such, it is a great way of helping build community around your project.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com