Change is inevitable. So version is a result of this reality. Every application will have a version history from alpha to beta, to production, to maintenance versions. Version management requirements of software teams may vary but principles and base process are same. As a software team, we had to define our processes so that the customers would get new versions with minimum pain. We aimed to cope with the reality of “Upgrade is painful”. Defining process is not enough, you should educate your staff and provide infrastructure for better version management.
Tools for version management is still weak. Vendors are still trying to define the borders of applications (Java Module System (inactive), JSR 277). (Web application and enterprise application separation has some problems for us. When we were trying to upgrade to newer Application Server, we noticed that you can’t share user sessions among web applications unless vendor’s proprietary web configuration parameters. For enterprise applications, it is totally impossible. We are about to configure our large application to bypass this limitation.) The reason of poor version management tools may be the result of vast deployment configuration environment. To support many application server, database server etc. is not easy. The problems or variety in middleware frameworks of Java may exhaust the time required to develop such tools. Anyway we should already have had these tools in our toolbox.
As an ERP team, we built the process and the tools for effective web application version management for better serving our customers. I’ll mention about these. ERP applications have a very large code base with many database tables. To keep the requirement change in minimum is almost impossible. Every project may lead to new tables, new columns, and new business logic.
Our version management infrastructure is as following:
1- Version Management Application: We needed such a tool to bundle web application for fast deployment. This tool prevents manual database scripts and automates this process. Every database change is defined in its repository and related versions may include these changes. Then using this tool we can package web applications as a zip file (bundle of EARs). This file is installed again with this tool in target system. This tool is just like Windows’ Add/Remove Programs. One can see what versions of applications are installed in his system.
2- Development and Version Servers (Staging Servers): At the beginning of our ERP development, we heard about staging servers but we didn’t know why we needed it (We had only development server). As the time passed and we installed our application to the customer systems then we understood that we should have system that has the same configuration with our customer systems. Then, we configured a version server in addition to development server. As our version within customers systems increased, we needed new version servers. At the end we had 3 version servers. Otherwise you can’t provide local version support for your customer. Supporting more version of your applications mean more servers and more development cost. A fix to older version may bring applying it to the newer versions thus it adds a burden on your developers, testers and release team.
We have version management process like below:
1- Minor (Fix) Versions: Any bug fix causes a new version. Accumulating these fixes into a single version is a good practice. Sometimes, some fixes may be very urgent and needs a fast version release period. A fix request is entered our bug system, then development manager inspects this problem then if he thinks that it is related with code then approve it for developer’s attention. Approved bug enters to the developer’s task list. Then the developer fixes the problem locally. Then he/she uploads his version into version server. Then testers do tests. If they confirms that the bug is fixed then they notifies the release manager. Release manager packages the web application then notifies support manager. Support manager announces bug fix for system managers. System managers get the fix and installs into their systems.
2- Major Versions: We have certain major version periods like one month, 2-months. ERP vendors’ major version period is longer such as 1 year, 2 year. In some projects, these periods may be changed. Sometimes, you need to release frequently so that new developments reflected to the target system earlier for customer tests. Development team does the required changes in the applications in the determined development timeframe (4 weeks). Then test period begins, testers make the tests during the test timeframe (1 week). After the bugs are closed by the developers (if satisfactory enough for release) then release manager packages the web applications from the development server. Then this version is installed to the target version server. We package from development server and install it into version server, because installation is an issue to test. Then testers test the version server for any installation problem. If no problem is found, that means we are ready to announce and release the version.
Web applications versions have following common characteristics with other type of applications:
1- Database Change Management: Every database-driven application has many database changes accompanying versions. To automate these changes are very important, because manual process is error-prone.
2- Application Code Changes: Business logic and application may change. Changing software artifacts should be packaged and installed to the target system without any manual process. Un-installation should be supported. Software pieces versions should be maintained otherwise we have no clue which version of software has the problem in the future.
Web applications versions have following distinctive characteristics:
1- Application should be packaged according to web deployment model. Currently Java EE Application Servers minimum deployable units are enterprise applications (EAR) that may include multiple web applications (WAR).
2- Enterprise applications can be deployed and restarted without server shutdown. This is a very important feature for system availability. An application version installation doesn’t bother the rest of the other applications’ users. After web application restart, you should handle session objects appropriately. After restart of web application, classloaders renewed and your users may get ClassCastException. Objects of same class loaded with different classloaders would cause ClassCastException.
3- Web application dependency is another aspect to consider. Some web applications may have some dependencies to other libraries or web applications. Classpath settings are important. Changing these settings may bring new ClassLoader problems. In this respect, knowing the differences between system classloaders and application classloaders are important.