Wednesday, August 1, 2012

Python 2.4 for Installation Scripting of Tomcat-based Application

The company that I work now was rolling out the application to one of our clients. It turns out the industry we are in favoured the Red Hat Enterprise Linux (RHEL) and SuSE Linux Enterprise Server (SLES). Our application runs on any platforms that Java supports, but for reasons clients have their own preference. Personally that time I have been using Ubuntu for desktop Linux more often. As the time goes by I need to hone my skills on the RHEL as well.

The approach with this client is a bit different from the rest, as we work together for almost one year to close the gap between the application and the business requirements through iteration. In the methodology that we use (Scrum) it is called "sprint". After each 2 sprints we need to deliver a working application to the client, which will be installed by their server admins. In the industry we are in, we usually are not allowed to access the server machines remotely. We need to deliver package with the instructions on how to install it and get it working. As this application is running on Apache Tomcat, we initially just bundle everything inside and deliver a tarball, database dump and installation instructions to the client.

As few iterations went by, new requirements and wishes emerged (as usual)!

Need to run the same application in the same machine in 2 different environment (database and TCP ports). We delivered 2 separated tarballs with ports hard coded.

Then there were needs to run more than 2 environments in single machine. This complicates the problem when you hard code the port numbers.

We shop around to see what open source installer options available, especially ones that can run well without GUI and very few dependencies need to be installed. Eventually we came into conclusion that we'd better develop our own installer script to have much greater control over what's happening.

I opt in for Python. It's there in most Linux/UNIX servers.

Ubuntu has Python 2.6 as the base of apt-get tools. Both RHEL's yum tool and SLES yast2 tool. All are sophisticated package dependency management tools!

I have (successfully) uninstalled Python 2.6 from Ubuntu, and also uninstalled Python 2.4 from CentOS.  Oh, please don't do this at home!

At least it's encouraging that Python actually serves at the heart of these wonderful Linux distros. You can't just get rid of Python on those distros.

We came with Python 2.4.x as the winner, as it is the lowest common denominator. Python 2.4 script will mostly run without modification on Python 2.6. You can't uninstall Python 2.4 from RHEL or SLES (at least not for now!).

The library side of the code is open sourced: http://code.google.com/p/swpt-tools/
But I still need some time to tidy up the code and wiki there.

If you have the same requirements like:

  1. Need to deploy an application running on Tomcat (or other application servers)
  2. Need to prompt and modify (or parameterize) on installation:
    1. values which will go inside the XML or properties files inside your Tomcat folders
    2. values that needs to go inside your WAR file
    3. values that needs to go inside your JAR file inside WAR file
    4. the installation folder location
    5. etc.
This project may be useful for you as well.




2 comments:

  1. wondering how the budgeting is calculated for scrum methodology project if they allow for new changes. is it time material basis or project/scope basis? or CR is a usual things in scrum development? :)

    ReplyDelete
  2. CR is a usual thing in Scrum. The thing is that CR shouldn't be put into sprint that is already started.

    Scrum doesn't allow changes on ongoing sprints. Customers are allowed to cancel an existing item in the sprint backlog, but not replacing or adding a new one. When request for new changes (we use term RFC instead of CR) coming during sprint on the run (which is most likely), that will be treated as a new request and should go to the product backlog.
    There shouldn't be any request to changes on the existing sprint backlog.

    Clients are not charged based on how many RFCs, but on how many sprints (and how many resources are committed to the sprints).

    ReplyDelete