Design of a Generic Patching Tool

As a release engineer, sometimes we need to release a patch to our customer to fix issues. Typically in a patch, it will include some files and the files will be contained in the patch by following the same file directories as the product, and it will also have scripts to update database objects. Of course it will have a release note and an installation guide. In the installation guide, it will typically require customer to check and take below actions:

1. Check the application version from customer’s side and ensure the patch is applicable.

2. Ask customer to bring down the web server.

3. Ask customer to copy files into application filesystem.

4. Ask customer to connect to database to update database.

Here, we can see things can be improved.

Firstly, those steps are very common and we can/should automate it.

Secondly, How could our customer know whether the patch has been applied already or not?

Thirdly, is it possible that customer can roll back the patch if it think the patch is a bad one?

So here I designed a generic patching to enhance above three things. You can view below design diagram on a new window.

patching

Let me introduce the steps in details:

The patch is maintained as,

(for example, the patch for bug#123456, and it will be maintained as below)

123456/

lib/

hibernate.jar

jdbc.jar

abc.jar

config/

tools.xml

list.xml

action.cfg

Help/

shopping.html

Note: in the action.cfg, it will determine the actions the patching tool should run. For example, it may have a pre-check to ensure that version of application is higher than 7.0. It will define the copy action and the database action.

Step 1,

It will ask you to bring down the services if it is required

It will check whether the version of application is applicable.

It will prompt for the Root Directory of your application, for example, if your application is installed in /u01/apps/shop/, then you can input /u01/apps/shop/ as Root Directory.

It will prompt for the database connection strings or database sid (if you have configured the TNS), and the database credential.

Step 2,

It will prompt for a confirmation of Go-Ahead.

Step 3,

It will scan the action.cfg file and back up all of the files which will get updated by patch#123456 under $ROOT_bak/123456/

Step 4,

It will copy and update the files in application file system.

Step 5,

It will scan the action.cfg file and store the database scripts included in patch#123456 to $ROOT_bak/123456/database_scripts/

Step 6,

It will connect to database and execute scripts.

Step 7, 

It will update the admin table to tell the system that patch#123456 has been pplied successfully.

My design here is a very simplified way to implement the patching tool. But it will definitely reduce duplicated steps. I think it can be enhanced in below aspects,

1. Error control enhancement.

2. Restart-able.

3. It should provide an option to just list all of the applied patches.