CC's Build System
Other Information
|
|
Automatic Deployment Interface
The automatic deployment system is for internal developers only and is
meant to simplify the tedious, error-prone process of creating releases for
CC's unique applications. It is intended to allow programmers and
activity developers to forget about the details of Maven and CVS and
create a easy to follow standard process for deploying projects.
However, this simplicity comes at a cost, since lack of knowledge by a
user may cause release information to be lost, so it is imperative that
users of this system understand it, understand their project in
relation to other projects, and never overwrite a previously released
version unless they know they are doing it. Although an overwritten
release can be recovered since everything will be in CVS, the
information retrieval will not be trivial. That is one of the
motivations of this process in the first place, since simply using CVS
tags for marking milestones can not guarantee the information will not
be lost and a release can be recreated. Self-referencing file catalogs
of a project with file versions and a tag name is used to keep that
type of information and it is checked into CVS. Then a version map is
maintained to hold project release versions, the last released version
of a project, it's dependencies and their versions, and the file
catalog's version number for the project. With all of that information,
there will always be enough information to recreate a release
deployment.
Many of the options may not make much sense
or seem useful for some developers, but as mentioned earlier, there are
multiple application setups that require these options. If a developer
is unsure of what an option will do, they should use the test
deployment interface (different web address than the normal deployment
page), which uses test cvs and deployment repositories. Otherwise, use
the Test Mode: option on the
main page.
Below is a screenshot of the top of the automatic deployment page:

The section of the deployment page in the image above has all of the
selectable options needed to execute a project's deployment.
The bottom
part of the deployment page shown below is mostly for informational
purposes:

The red numbers are not on
the
actual page, but are added here as markers for the descriptions that
follow.
- The Repository:
entry on the first line is the root of the CVS repository. It is
configurable on the server only.
- The Repository Module:
selection box has a list of all the buildable Maven projects in the CVS
repository. Some modules can be excluded from the search if configured
on the server. On initial loading of the page, the first project
viewable in this selection box will load values for the other options.
Otherwise, when the value of this selection box is changed, the page
will be reloaded with values for the newly selected project.
- The Deploy Directory:
option is used to select the final server/directory for the deployment
and to retrieve dependency artifacts. This is very important because
higher level projects can't be deployed to servers that depend on
artifacts that it can not download from the same server unless a
complete build is done. The reason the deployment will fail is because
Maven downloads dependencies before trying to run any goal and we need
to ensure that clients will be able to download dependencies when
needed, so we point Maven to the same server that a client would point
to (see the Check available releases
option). The deployment directory list is obtained from the
Projects/Builds/deployment.locations file in the CVS repository listed
at the top of the deployment page, so they new locations may be added,
deleted, or edited by checking out the file and modifying it.
- Check available releases
checkbox is used to make sure dependency releases are available on the
server we have selected. When this checkbox is enabled, the
informational section at the bottom of the deployment page will be
updated with a checkmark icon next to any dependency releases listed.
If the dependency release is available on the server, it may be
selected to be used as a the dependency version for the current
deployment. The first time this box is selected, it will reload the
page, but once it is selected, the availablility of the dependencies
will be checked anytime a new module is selected.
- The Jnlp release
checkbox is used to indicate the the deployment is a jnlp deployment
rather than a jar deployment. It is up to the developer to know whether
the project is a jnlp project or not as special parameters must be set
in the project's project.xml and project.properties files (see the ccjnlp plugin docs).
- The Project Release
Version: edit box is for specifying the actual release version
number or name for the project and it's dependencies (depending on the
option selection combination). Be sensible with the naming; choose a
name that may mean something or ties into a naming standard and try to
avoid non-alphanumeric characters other than periods, dashes, and
underlines ( '.', '-', '_' ). Also, check if there is a release with
the same name already. If there is and you do not enable the Mapping For Re-Releases option, you
will overwrite the mapping information for the earlier release.
- Test Mode: is used
for testing the build without actually deploying it to the server or
effecting CVS files, so changes from testing will not available for
later releases. Dependencies will be accessed locally for multiproject
builds by using the maven.jar.override
property rather than downloaded from the server, since a new dependency
version may not be on the server if it wasn't deployed before the test
run. This option is very important for testing large multiproject
builds where it is unclear whether dependencies are compatible with
each other.
- The Restore Project After
Release: option is used to put the project back in the state it
was before the deployment was performed. Usually, projects should have
most of their dependencies specified as SNAPSHOT versions for
development so developers will always be assured they are getting the
most up-to-date versions of the dependencies. During the deployment,
the dependency versions should be specified as a specific version
rather than a SNAPSHOT so the release is essentially frozen at that
point. So, the deployment will change the dependencies to particular
versions specified by the options in the deployment web page, check in
the project.xml file, make a catalog, and tag the files for the
release. After the deployment has completed, the old project.xml file
will be placed back on the HEAD of the CVS project, making the project
ready for development again.
- Mapping For Re-Releases:
option is what allows us to re-release an old release reliably. The map
refers to mapping release versions to a project, the dependency
versions for that release, and a file catalog version in CVS for a
listing of all the project's files. The mapping can be done during
multiproject builds so a recursive mapping can drill down through all
dependencies that a project may consist of. If this option is selected
and the matches a previous release for the project, the information
from the map will be used to recreate the deployment. If this option is
not selected and there already exists a mapping for the release
version, it will be overwritten with the new information and CVS tags
will be moved, so it is very important to check available releases
before naming a new one. This option is not available for multiproject
builds using this interface because the map already has dependency
versions specified and selecting new versions doesn't make any sense
since it the Build Project and
Dependencies option allows for that with less steps.
- Build Project and
Dependencies: is used to create a multiproject build that will
recursively build the project, all of it's dependencies, and any
dependencies they may have. Specifying dependency versions will cause
all uses of that dependency to use the specified version so it is
ensured that all jar files are compatible.
- Update All Dependency
Versions: is used to create a multiproject release so all
dependencies and the project itself will be released as the release
specified in the Project Release
Version edit box. This is the default for multiproject builds
since a release should mark all components at that time as part of the
release. Again, previous releases with the same version for the project
and dependencies will be overwritten in the map and CVS tags will be
moved, so it is very important that a unique release version is
specified or the developer knows what they are doing.
- The Dependency
column lists all the dependency project names for the currently
selected project. If the dependency is a link, a user may click on the
link to reload the page with the dependency as the new currently
selected project. This is helpful when a dependency must be released
before the major project.
- The Project Version
column lists the version of the dependency in the current selected
project's project.xml file. These values will be restored after the
deployment if the Restore Project
After Release option is enabled, or if not enabled, will be
updated to the values selected in the dependency's Release Version column.
- The Last Released Version
column indicates the last entry from a release in the version mapping
file for the dependency. If there is no entry for a dependency in this
column, it means there is no last release for it. This entry will
change after the deployment if running a multiproject build with the Update All Dependency Versions
option enabled.
- The Release Version
column is for specifying the dependency version. These selections will
have no effect if using the Mapping
For Re-Releases or the Update
All Dependency Versions options. If a dependency is marked as
not configurable, it means it is not a CC project or is not buildable
through this interface.
- The Try Release button
is used to submit the form.
- The Project Name
column is from the project's POM <name> attribute.
- The Project Path
column indicates it's location on the cvs server.
- The Last Released Version
is the last released entry for this project in the version map, the
same as for he dependencies.
- The Project Version
is from the project's POM <currentVersion> attribute.
- The Project Parent
is listed here, if a project has a parent, so that if there is any
problems building or Maven activity is not correct, it may be checked
out and the project can be built offline.
- The Released Versions
column is for previous releases listed in the version map. Clicking on
the link will cause a changelog report to popup.
- The Catalog Version
indicates the file catalog CVS version number for the release. This
will contain the tag name and all the files names and CVS versions for
all the files in the project. The file catalog is in the top of the
project tree for each project.
- The Dependency
column indicates the dependencies used in that release of the project.
- The Dependency Version
column lists the dependency version for that release of the project.
|