The Enterprise Designer Integrated Development Environment (IDE) is the Java CAPS development environment. It contains project and environment explorers and a series of editors, one or more for each of the products, the connectivity map editor and the deployment profile editor. Solutions under development are organized into projects. Projects are collections of subprojects, Collaborations, Business Processes, Object Type Definitions (OTDs), Connectors, and other development-time artifacts, which appear as subnodes to a project. Projects can be nested. Components from one or more projects can be used to build an Enterprise Application by creating a connectivity map that includes all required components, wherever they may be located within the Java CAPS Project hierarchy. Developers have a great deal of flexibility in organizing development artifacts into projects and project hierarchies. This chapter explores some of the options for managing projects in Java CAPS at design time, migration from environment to environment, and structure of environments. It also discusses selected deployment architectures suitable for small and large deployments and command-line build and deployment tools.
Many factors influence the project structures an organization might adopt. Some of the influencing factors are best practices that an organization may already have adopted for management of development processes, the size of the software development department, the nature of the application, and the preferences of the administration team responsible for the promotion process of a project through the testing, user acceptance testing (UAT), and production environments.
It is fair to assume that all environments fall somewhere in the spectrum from a single PC that is running under a desk to a highly available, clustered production environment with tightly controlled development, test, UAT, load testing, and production environments.
Chapter 2, section 2.5, discussed the stages in which Java CAPS solutions are developed.
The logical solution defines how project components process messages, how they receive and parse data into message structures, how they transform messages, and what protocols are used to pick up and deliver messages to end systems with which the solution will communicate. All development artifacts that jointly define the Enterprise Application are arranged and connected using the connectivity map. The connectivity map is a graphical view of the project’s connectivity.
While some decisions on the physical aspects of Java CAPS solutions are made in connectivity maps, most physical aspects of Java CAPS solutions are made in the environment containers and associated with the logical solution through the deployment profile.
Physical aspects of the project, established through the deployment profile, include where the Enterprise Application is to be deployed and the connection properties its eWays use to make connections to the end systems. Java CAPS environments define the number and types of Integration, Application, and Message Servers and their properties, and the number, the kind, and the runtime configuration properties of external systems. The same logical solution can be deployed to different Java CAPS environments and therefore to different Integration, Application, and/or Message Servers as well as external systems with different configuration properties.
This separation between the logical solution and its physical environment allows Java CAPS solutions to be developed once and deployed to different environments, including solution testing and migration environments, from development to production.
Java CAPS projects are arranged in hierarchical, directory-like structures. These hierarchies contain collections of OTDs, Java Collaboration Definitions (JCDs), XSLT Collaboration Definitions (XCDs), XML Schema Definitions (XSDs), Web Services Description Language (WSDL) interface definitions, Business Processes, JMS Destinations, library jar files, and other artifacts that are used to create Java CAPS integration solutions. These components can be arranged in many ways, from a single project (a large bin approach) to many projects, possibly with subprojects, projects for common components, and projects for unique solution components.
This section describes one of the possible project structures, using a step-by-step definition approach, and discusses the reasoning that led to the development of this structure.
Note
The structure discussed below is only one of the possible project structures. This structure is tailored to large deployment environments. Other structures are possible and, depending on circumstances, may be more appropriate.
Let’s start by creating a project folder under the eDesigner Project Explorer’s root directory. Figure 3-1 shows an example of a root of project hierarchy.
Note
The name of the project influences the name of the resulting Enterprise Application Archive (EAR) file. In Java CAPS releases prior to release 5.1.3, it is not possible to change the name of the EAR file; hence it is important to consider the project directory name and directory hierarchy depth. Best practice is to adopt a standard naming convention, such as the four-layer naming convention corresponding to the four service-orientated architecture layers. Adding a prefix, for example, “bp” (business process) or “bs” (business service), followed by the name of the project, might be adopted as a practice to derive a name of a project directory. With such structure, the services created in each category will be listed one after the other under the root directory of the Enterprise Designer.
Within each directory, a subdirectory will be created to contain the artifacts of the appropriate category. XSDs, WSDL interface definitions, OTDs, JCDs, XCDs, Business Processes, JMS Destinations, external library JARs, and external systems and connectors all would have a separate directory whose name would correspond to the category of objects it contains. Figure 3-2 shows a project hierarchy in which subprojects follow this sort of convention.
Once development of project components is complete, a connectivity map and a deployment profile for the project can be created.
Unlike other project components, which can be created in arbitrary locations within arbitrary project hierarchies, connectivity maps and their corresponding deployment profiles must exist in the same directory. Components defined through a connectivity map in one project directory are not visible to a deployment profile in another project directory.
Let’s create a project’s connectivity map(s) in the project’s root directory; see Figure 3-3. An enterprise application may have more than one connectivity map. When a project is large, it is a good practice to break it up into logical groupings and create connectivity maps for each grouping, interconnecting connectivity map–based groups with JMS queues or topics.
Processing components, JCDs, Business Processes, and XCDs, can be dragged and dropped onto the connectivity map directly from project directories in which they were created. Figure 3-4 shows a connectivity map constructed from components available in different project directories.
JMS Destinations, queues, and topics, as well as Web Services and HTTP connectors, can be explicitly created from the project context menu, so you can create them anywhere within the project hierarchy. Other connectivity map objects, most notably eWays but also eView applications and scheduler connectors, can only be created by selecting them from a drop-down menu in the Connectivity Map Editor. This causes them to be created in the same directory as the connectivity map. You can leave them there or use cut and paste to move them to the “deploy” directory to keep the root of the project tidy.
As will be discussed in Chapter 5, “Messaging Infrastructure,” section 5.6.1, JMS Destinations with the same name, even if used in different connectivity maps, are, for the JMS Message Server, the same destinations. With multiple connectivity maps, intended to use the same JMS Destinations to interconnect project components, it is easy to accidentally misspell a destination name, unintentionally causing distinct destinations to be created and effectively disconnecting components. This is a consequence of automatic destination creation. This kind of error is difficult to diagnose at development time. When working with enterprise systems that consist of components sharing JMS destinations across connectivity maps, it is advisable to create a queue directory, at the root level of the Repository or a related group of projects, for the global JMS Destinations and, possibly, create a per-project queue directory for local JMS destinations. In the example in Figure 3-5, a local project queue directory and a global queue directory were created.
Deployment profiles must be created in the directory that contains all the connectivity maps whose components are to be included in the resulting EAR. As the default name of the resulting EAR file is a combination of the project folder name and the deployment profile name, it is best to supplement the deployment profile name with a number. This number can double as a build number when new deployment profiles are created, incrementing the deployment profile number with each subsequent build. Figure 3-6 shows deployment profiles whose names follow this convention.
We would expect to see both connectivity maps and deployment profiles in the deploy directory of the project. If we were to place the deployment profile in the deploy directory, the resulting EAR file would have the name bs_TestService_u002F_deployTST_1. The extra directory depth results in the sequence _u002F_ gratuitously inserted into the EAR file name. Therefore, it is perhaps cleaner to place deployment profiles in the root directory of the project to avoid this. The downside is that connectivity maps must also be placed in the root of the project. In addition, as mentioned before, connectors created through connectivity maps will be created in the directory where the connectivity map is and may need to be moved.
The name of the EAR file has a maximum length of 32 characters. Default EAR file name is generated from directory names and the deployment profile name. If the concatenated directory names and deployment profile name exceed the maximum length, the generated EAR file name embeds a part of the original path and a unique number. This may make the EAR file name difficult to relate to the original project. Default EAR file names are as follows:
32-character filename from the name of the project directory bs_TestService and the name of the deployment profile TST_1_max_length_1
bs_TestServiceTST_1_max_length_1.ear
33-character filename from the name of the project directory bs_TestService and the name of the deployment profile TST_1_max_length_12
bs_TestServiceTST _1_max_1294795462.ear
It is recommended to use the desired name as the name of the parent directory of the project, create the deployment profile under the root directory of the project, and include a build number in that name. The total length of the name should not exceed 32 characters.
Project directory name + deployment profile name <= 32 characters
As discussed in Chapter 2, section 2.5, most configuration settings related to the physical environment in which a solution will operate are associated with external system containers in the Java CAPS environment. These settings are inherited by the enterprise archive through the deployment profile and the build process. Each deployment profile can be created for a distinct Java CAPS environment, allowing different settings to be associated with different physical environments like development, test, staging, or production. Some settings, however, are configured through the connectivity map connectors. These will be inherited by all deployment profiles, which may not be desirable. Some settings may be used by multiple connectivity maps. Setting them individually in each connectivity map may be error-prone and burdensome if a change must be made. To facilitate externalization of such settings, Java CAPS project variables and project and environment constants can be used.
Environment constants must be created in the Java CAPS environment in which they are to be used. Project variables and project constants must be created in the same directory as the connectivity map in which they are to be used. Project constants are useful if the same fixed values are to be used in multiple connectivity maps in the same deployment. This could be a constant representing, for example, a name of a log file that all components must use. Changing the value of the constant will cause the new value to be used in all connectivity maps in which it is referenced.
Project variables are useful if a property, which is set in the connectivity map, must vary from environment to environment.
Two project variables with names and types, one for an input file name and one for an output file name, are shown in Figure 3-7.
Once created, the variables are available to be used as values of any connectivity map connector properties. For example, let’s select the “out” file connector in the connectivity map shown in Figure 3-8, then select the output file name parameter and select the outputFileName variable from the drop-down menu. This is illustrated in Figure 3-8.
Before a project that uses project variables can be built, runtime values must be associated with the variables. Deployment Profile Editor’s “Map Variables” button opens a dialog box that lists all project variables used in all connectivity maps for which the deployment profile is being constructed. The value of each variable can either be provided as a literal or substituted at build time through an environment constant. Providing a value as an explicit literal makes it deployment profile–specific; it is therefore recommended to use environment constants to provide build-time values for project variables.
To provide environment-dependent build-time values for project variables, it is necessary to define environment constants, using a dialog box similar to the one shown in Figure 3-9, for each of the Java CAPS environments for which the solution will be built.
Once constants are defined in the environment and the variables have been selected in the connectivity map, the deployment profile can be configured through mapping constants to variables, using controls in the dialog box similar to the one shown in Figure 3-10.
Using project variables and environment constants, it is possible to create deployment profiles from a single connectivity map in which connector properties need to vary from environment to environment.
Since Java CAPS Repository will contain development artifacts that do not exist elsewhere, it is important to maintain external copies should restoration be required. In addition to the operating systems backups, which make a copy of the entire file system directory containing the Java CAPS Repository, Java CAPS provides functionality to back up the repository contents and import and export individual projects or project groups.
Repository backup and restore scripts are provided in the <JavaCAPS Install Dir>/repository/utils and are documented in the eGate Integrator System Administration Guide [eGateSAG]. Repository backup operation backs up all versions of the projects objects.
Individual projects and project groups can be exported and imported using the Enterprise Designer or using export and import scripts provided in the <JavaCAPS Install Dir>repository/utils directory. Unlike repository backup, where all objects and all versions are backed up, project export only exports the current version of all objects in the selected projects.
To export a project using the eDesigner, right click on the project name and choose export, as shown in Figure 3-11.
It is possible to export not only a project by itself but also the project and any Java CAPS environments that may be the project’s deployment targets. Figure 3-12 shows a list of projects that can be exported with one project chosen for export. Exporting Java CAPS environments will preserve a snapshot of environment settings at the time of export.
Having project exports include Java CAPS environment settings plays a key role in release management when an external source control system and a single repository are used for all environments.
When a project is exported, any dependent projects will be exported with it. A dependent project is any project that has any of its objects referenced by the project being exported.
It is recommended, as best practice, that shared objects like queues or OTDs are created in project directories of their own. An example of this is the global queue project/directory discussed earlier.
Java CAPS provides the facility to import projects into the repository. Project import into a new Repository may be necessary when:
Separate development and production repositories are used
There is a need to import an older version of a project to roll the project back to an earlier state
A project developed elsewhere is to be included in the solution
You import a project the same way you export a project, choosing an “import” option from the right-click menu in the Project Explorer (see Figure 3-13).
When importing a project, you must consider the following matters:
Deployment profiles are not exported; hence it will be necessary to create them after importing a project.
If the project already exists in the Repository, it is not possible to import the project without overwriting the current version of the project. This is desirable if there is a need to roll back to an earlier version of a project. Best practice is to rename the existing project <projectname>_latest and import the older version under the original project name.
If the project has dependent projects that already exist in the Repository, import options will be given for the subprojects. Care must be taken not to import previous versions of dependent projects and thereby overwrite the current version. If the best practices are followed (where shared resources such as queues and OTDs are in global projects/directories), this issue can be minimized.
Let us examine options available to manage deployments in Java CAPS. We look at the built-in version control functionality, contained within the product, and how we can work with other source control/release management products.
Java CAPS has built-in functionality that allows management of versions of project components. We look at some of these features in this section. For a full description of these features, please refer to the Java CAPS eGate User Guide.
Let us start with the basics: check-in, check-out, and viewing the version history of components.
When a component is checked in to the version control system, it is locked against modification until checked out, and a lock is displayed in the component’s icon in the Enterprise Explorer, as shown in Figure 3-14.
When the latest version of a component is checked out from the version control system, it is locked against another user checking it out. A writing pad icon is displayed next to the component’s icon in the Enterprise Explorer, indicating that it is checked out and therefore cannot be modified, as shown in Figure 3-15.
When any version of a component is retrieved from the version history dialog, it is not locked against another user checking it out or retrieving it. A combined writing pad/warning icon is displayed next to the component’s icon in the Enterprise Explorer, indicating that it is in your workspace but warning you that it is not locked in any way, as shown in Figure 3-16.
You can access a component’s version history through the Version Control menu, shown in Figure 3-17. Version Control History, similar to the one shown in Figure 3-18, allows viewing of version and tag history and retrieval of selected versions of objects to the workspace.
Version control allows you to maintain multiple versions of selected projects or environment components within a particular branch of the Repository. Version history of each component is recorded in a log file and can be viewed by means of a menu option.
Note
Note that more then one person logged into the Enterprise Designer using the same User ID will circumvent the version control system’s check-in/check-out locking mechanism and may result in one person’s work being overwritten by another’s work. When multiple developers work with project components, each must have a unique Enterprise Designer User ID.
Repository branches enable you to isolate different versions of a specific project from each other. This allows maintenance of a stable version deployed to the production environment, for example, while working on a new version in the development environment.
At initial installation, the Repository has a main branch labeled HEAD, as shown in Figure 3-19.
Typically, a project is developed in the HEAD branch. When the project is ready to deploy to the production environment, a separate branch is created to contain that version of the project. The next version of the project is then developed in the HEAD branch.
When a project component is modified in a branch, the changes are confined to that branch; other branches are not affected.
You can tag components either individually or as collections so that they can be retrieved for deployment by specifying the tag name. When a component, such as a project, is selected for tagging, all components contained in the project that are eligible for tagging are automatically included in a list, similar to the one shown in Figure 3-20. You can deselect individual components from the list if desired.
If a project contains subprojects, you can add the components contained in them to the list by checking the Recourse Project checkbox (subprojects themselves are not shown in the list). Only components that are checked in can be tagged; components that are checked out will be shown in the list but will be dimmed and deselected.
The Deployment Profile Editor allows control over which version of the various project components get mapped in the deployment profile. The editor provides a spreadsheet-like view that displays project components and their versions. This view includes the component name, project path, current version in the users’ workspace, tag on the version (if there is one), and to what external system the component is mapped.
This view is enabled by clicking the Spreadsheet View icon, like the one shown in Figure 3-21, in the Deployment Profile Editor toolbar.
The spreadsheet view has an option that is checked by default to show only those components that are eligible to be deployed, showing a component table similar to that shown in Figure 3-22. If not checked, components not ordinarily seen in the deployment profile (for example, the connectivity maps and OTDs) will be listed as well. Listing all components allows you to also specify the version of those components, whether they are deployable or not.
The spreadsheet view allows you to specify the version for each component by selecting a version or tag from a drop-down list. Selecting versions or tags does not affect your workspace but is only for setting up the versions to appear in a snapshot; only when the snapshot is retrieved will your workspace be modified.
The Deployment Profile Editor allows you to take a snapshot of the configuration currently in your workspace, as shown in the spreadsheet view. Clicking the “Snapshot” button presents a dialog, similar to the one shown in Figure 3-23, in which you enter a name for the snapshot.
The Deployment Profile Editor gives you the option of deploying the latest component versions from the Repository or those versions recorded in a snapshot of your workspace at a previous time. Clicking the Global Settings button presents a dialog, similar to that shown in Figure 3-24, in which you can specify your choice and, if appropriate, name the desired snapshot.
In either case, if your chosen configuration is different from what is currently in your workspace, you will receive another dialog informing you that the action will modify what is in your workspace and offering you the opportunity to not perform the operation.
If you select a specific snapshot that is different from what is currently in your workspace, the versions of those components used by the deployment profile that are part of the specified snapshot will be retrieved into your workspace as read-only versions.
If you select to use the latest Repository versions while another configuration is currently in your workspace, those components used by the deployment profile that are currently in your workspace will be removed and replaced by the latest versions from the Repository.
It is often found that an organization already uses a concurrent versioning system (CVS) or other source control system for release management of projects and services.
As we saw in the previous section, Java CAPS has its own source control functionality. Unfortunately, the Java CAPS repository file system does not allow its objects and files to easily be checked in and out by external version control systems.
This issue can be worked around by checking into the third-party version control system complete builds (the EAR files that are created) and the corresponding project exports. Exports contain the current version of project objects and code as well as the current environment settings and project configuration. This enables the organization to track changes and tag and redeploy earlier versions of services where necessary. This also enables monitoring and a single system control point for the testing and release process.
When using a third-party source control system, the only Java CAPS objects that can reasonably be managed are project exports and project builds. In this section we look at the process in more detail. Specially, the following questions will be addressed:
How do we manage our releases in conjunction with a third-party source control system?
How do we roll back to an earlier release to fix a bug?
How do we apply bug fixes to the current project code base?
Let us answer these questions, detailing the steps in releasing a project/service. We also look at best practices and the additional artifacts that should accompany such a release in the source control system from a service/project governance viewpoint.
The following discussion covers the general release process from service specification through implementation, deployment, and test.
At the start of a service development life cycle, the requirement and design documents for the project/service are checked in to the source control system. This results in the project’s code and the supporting documentation being tagged at the same time, showing the release and modification history for the project. Figure 3-25 depicts the process.
Once the project has been built in Java CAPS, we
Check in the EAR file and the project export zip file.
Deploy the project EAR file (retrieved from the source control system) to the Java CAPS domain in the environment using the Enterprise Manager.
Test the project and check in test results to the source control system.
The iteration is complete.
For the next iteration, we modify the code base to implement the new functionality specified in the next phase documentation.
In the event that an issue is discovered in a previously released version of a project, it is a requirement that we can revisit the code and settings of that release. This is achieved by the process depicted in Figure 3-26 and discussed below.
Rename the project that we are currently working on <projectname>_latest before we import the earlier version.
Make the changes to fix the bug to the imported project code.
Build the project and check in the resulting EAR file to the source control system.
Export the project form the Java CAPS Repository and check in to the source control system.
Deploy the project and test bug fix.
Update project documentation with test results in the source control system.
Take note of the changes that were applied to fix the bug.
Delete the imported project directory.
Rename the <projectname>_latest project directory <projectname>.
Apply the bug fix you have recorded to the code base.
Deployment environments come in all shapes and sizes, from the under-the-desk single-box environment to cooled server room with clusters, grids, and virtualization. In this section we look at the options to be considered when deploying Java CAPS in a small environment and in a large environment.
On a single-box deployment, diagrammatically shown in Figure 3-27, there will be one Repository, one Enterprise Designer, a Domain for each environment, and an Enterprise Manager for monitoring the domains. Optionally, we may also have a UDDI Server for publishing and discovering WSDL files.
As we can see, there are several moving parts in the deployment. These can be grouped into design time and runtime components, two each.
The design time pieces are the Enterprise Designer for creating the solution and the Repository for storing the artifacts that make up the solution.
The runtime pieces are the Domain for running/executing the processes and the Enterprise Manager for monitoring and managing the solution.
The only component that needs to be running is the Domain corresponding to the environment, for example, the Production Domain. For monitoring, you would also require the Enterprise Manager.
Using the Enterprise Designer’s Environment Explorer tab, you would configure the settings of the end systems in each environment. Figure 3-28 shows a Java CAPS Environment Explorer with a number of separate environments, whose names are reminiscent of the purpose for which they were created.
In the example there are environments named DEV, TST, UAT, and PRD. In each of the environments the combination of the settings in each of the external systems (eWays), the Integration Server, Message Server, and environment constants shows the combination of logical and physical aspects of the project. Ideally, the only configuration changes required for a project to be deployed between DEV and TST, for example, should be contained in the environment settings.
Once the project is built, there are three options for deploying the Enterprise Archive to the runtime environment: using the Enterprise Designer’s “Deploy” button, using the Enterprise Manager’s Deployer, and using a deployment command-line utility (deplocli). In a single-machine environment, either method is appropriate; however, if there is separation of duties between the developer and the administrator/deployer, it is recommended that the administrator/deployer use the Enterprise Manager or the command-line deployer tool.
When we come to creating the structure for a clustered environment, we have an option to create one or two repositories. Let’s discuss the pros and cons of both architecture deployment options.
Environment assumptions include the following:
One machine for development, test, and UAT environments
A production environment consisting of a clustered setup of two or more machines connected to shared storage, the storage area network (SAN)
If Java CAPS is deployed in a one-Repository configuration, as shown in Figure 3-29, all the environments are maintained in the one Repository. This makes maintenance of the platform and the environments easier.
When upgrades are required, they need only be applied to the one Repository. This eliminates issues around the levels of versions and patches (ESRs/hotfixes) between environments.
Some organizations maintain two totally separate environments with all components replicated, Repositories, logical hosts, queue managers, and so on. Figure 3-30 shows a two-Repository setup.
In this architecture, each project needs to be exported from the development/test Repository and imported in to the production Repository. This raises the following disadvantages:
When a project is exported, all components are in the export zip except the project’s deployment profiles. Deployment profiles must be created again. Java CAPS Enterprise Designer knowledge is required.
When automation of the deployments is required using the command-line tools, complications arise, as we see in section 3.7.
The advantages, on the other hand, are as follows:
Once a project has been promoted to the production Repository, we have a version of the project that is under deployment control of a new environment. Control and access to this Repository can be restricted to one administrator.
As the version of the project/interface is in the production Repository, it is isolated from development changes; so if a bug is discovered in the production code, it may be fixed without the risk of having to deploy untested changes to production from a development branch of the code.
The versions of patches on the overall environment can be more tightly controlled by the production administrators.
Java CAPS includes command-line build and deployment tools. The scripts discussed in this section are examples of scripts that can be used to build EAR files and deploy the files to their environments.
To build your services/projects using scripts, you need to download from the Repository the commandlinecodegen.zip file.
The installation of the command-line utilities requires you to install Apache Ant on the same box. Once Ant is installed, you can commence the build process by calling the ant.bat file in the commandlinecodegen directory with appropriate project settings. The eGate User Guide discusses this in some detail.
A more automated approach is to run these commands from an Ant script. A Java IDE, for example NetBeans, can be used to execute the Ant script. The following sample script builds an EAR file for a project. A slight amendment to remotebuild.xml file, in the commandcodegen directory, has been made to allow the script to work. The change is setting the settings for the Repository in the remotebuild.xml file in its init section.
The sample build script is shown in Listing 3-1.
Example 3-1. Project Build Script
<?xml version="1.0" encoding="UTF-8"?>
<project name="Build Sample Service" default="all" basedir=".">
<target depends="build_EAR, deploy_EAR_DEV" name="all">
</target>
<target name="build_EAR">
<ant antfile="remotebuild.xml"
dir="C:JavaCaps5.1.2commandlinecodegen" >
<property
name="commandline.rep.projectName"
value="bsSampleService" />
<property
name="commandline.rep.projectDeployName"
value="DEV_1" />
</ant>
</target>
</project>A sample deployment script is shown in Listing 3-2.
Example 3-2. Project Deployment Script
<?xml version="1.0" encoding="UTF-8"?>
<project
name="Build Sample Service"
default="all"
basedir=".">
<target
depends="build_EAR"
name="deploy_EAR_DEV"
>
<exec
dir="C:/JavaCaps5.1.2/deploy/"
executable="cmd"
>
<arg LINE="/c"/>
<!—
deploycli.bat
-host eaidev1
-port 50100
-u Administrator
-pass homers list"/>
-->
<arg value="deploycli.bat"/>
<arg value="-host"/>
<arg value="eaidev1"/>
<arg value="-port"/>
<arg value="50100"/>
<arg value="-u"/>
<arg value="Administrator"/>
<arg value="-pass"/>
<arg value="homers"/>
<arg value="deploy"/>
<arg value=
"C:JavaCaps5.1.2commandlinecodegenlocalrepositoryDESTuildssSampleServiceDE
V_1lhIntegrationSvr1sSampleServiceDEV_1.ear"
/>
</exec>
</target>
</project>Based on the experience of the author, best practice is to deploy a single Repository and adopt the release management strategy described earlier accompanied by an external source control system or a governance repository.
Develop the build and deployment scripts for each of your services that you create. This simplifies the release management process further down the line.
Deploy Java CAPS with one Repository and manage all your environments from this repository.
This chapter explored some of the options for organizing and managing projects in Java CAPS. Both design-time structure and organization, the use of variables for environment independence, and version control aspects of development were discussed. Issues of migration from environment to environment, structure of environments, deployment architectures suitable for small and large deployments, and command-line build and deployment tools were also discussed.