The last couple of years I have worked in several technical roles on projects around WebSphere. All projects are easily characterized by a split between a development organization and an operational support organization.
The development project creates software solutions based on specific functional and non-functional requirements. And the operational support organization is responsible for deploying the software assets on the server components according to the deployment instructions (manual) from the development team which should be based on the general deployment guidelines which have been set out by the technical architects team.
Continuous integration & hand over to operational support
For a development team automated deployment could be part of continuous integration. That means a daily build that includes deployment on a integration test server followed by an automated smoke test, which could be a full automated functional regression test. Once a development team completes a iteration of work, it delivers the products to the other team. This hand over process should include some knowledge transfer.Deployments accross several environments
The operational support team might be split up into a test, acceptance and production team. They will deploy the recieved version of the application on the test environment and will inform the test teams to start testing. The same version of the application with some environment specific settings will end up in the other environments.Growing deployment requests and complexity
The operational support team is likely to recieve multiple application deployment request from different development teams and need to deploy the same application in different environments depending on the state of testing. All of this leads to the situation where a lot of deployment steps are defined, which are different for each application and have special settings for each environment. If these deployment steps are performed manually, errors are likely to occur. These errors will cause errors in the application for which the operational support team will get the blame and causes the test teams to spend less time on functional testing.Need for automation
To improve the quality of deployments and to prevent errors, all steps in the deployment process need to be implemented using an automated deployment tool. These steps differ per type of application. A portal application would typically require ear files to be deployed, content to be deployed, portlets and pages to be defined, portlet settings to be defined, dynamic portal page extension nodes, authorization settings, etc. etc. Other applications might need to deploy: Database deployments (SQL scripts, stored procedures, indexes, etc) MQ queues & Queue managers, ILOG Rule archives, LDAP ldfif imports, etc. etc. and of course a lot of base WebSphere stuff, like JDBC, JMS, SIB, Mail Provider resources, JVM settings, EAR file resource bindings, etc.First concepts
Part of all of this deployment information is considered to be related to the target environment and part is related to the project set of applications that are deployed together. The application part is further divided into a configuration part, a content part and a "binary" part (the things that stay the same in each environment).
A deployment than consists of selecting:
In the coming blogs I will discuss how deployment automation can be established by creating your own framework or by using tools that are available in the market. For now let me just say that all frameworks and tools are build on top of the deployment capabilities that are found inside the target runtime. For WebSphere the core tool is wsadmin and Jython, whether it is abstracted in a tool or not.
- The target environment
- The project set of applications
- The release/version of that project set
- The type of deployment task (deploying configuration or content or binaries)