Administering Moves

The entities that need to be administered for moves are listed below.

1. Quick Start
2. #Repositories
3. #Environments
4. #Stacks
5. #Containers
6. #Applications
7. #RemovingArtifacts

In general you should set entities up in the order that they appear above. The entities are described in detail below.

Repositories

Repositories are maven repositories, accessible to moves over http/https. An example is the the SAIS Group repository at https://mv-ezproxy-com.ezproxyberklee.flo.org/nexus/content/groups/saisGroupRepo. Maven has a well defined format, which specifies where to find an application within a repository. Each Application has an 'ArtifactId', a 'GroupId' and a 'Version'. So, for example, moves itself has artifactId=sais-moves-web, groupId=edu.mit.ist.es, versionId=2.0.0. Maven will translate this, by default into a final location of https://mv-ezproxy-com.ezproxyberklee.flo.org/nexus/content/groups/saisGroupRepo/edu/mit/ist/es/sais-moves-web/2.0.0/sais-moves-web-2.0.0.war" The properties you need to configure for a repository are:

• server (e.g. maven.mit.edu)
• port (e.g. null - if port is null, moves uses the default port for the protocol supplied)
• protocol (e.g. https)
• base url (e.g. /nexus/content/groups/saisGroupRepo)

The base url can contain the following replacement properties.

The values for all parameters except 'version' are specified in the Administration -> Stacks -> Application section of moves. The version is selected during the deploy/build workflows by the user who has requested a deploy/build workflow.

Note that in order to access the MIT repository, you must also have correctly configured SSL access and a Maven username and password that is authorized to view the repository you have configured. See the properties webservices.trustStore, webservices.trustStorePassword, mit.maven.repository.username and mit.maven.repository.password as described in the page Moves Property File settings for details.

Note that when you have configured an app that has at least one release in the MIT repository, you can test repository connectivity by going to Administration -> Stacks and clicking on the 'ping app' icon ( ) for your app. The resulting page will look like the following:

If your app and repository are configured correctly, versions that exist in Maven should appear on the resulting page. You should be able to click on the download icon ( ) for any page and save the application binaries to your hard drive. (Tip: open jar, war or ear files using winzip or any other program that will allow you to verify that the downloaded application is valid.
If you cannot download an application using this test, you will NOT be able to deploy that application using Moves!!!

Environments

Environments are really just a lookup that identifies the function of containers within a stack. The standard environments are 'Production', 'QA', and 'Development'. These are already set up when Moves is deployed, so they will not need to be changed. However, we allow creation of new future environments (for example 'Continuous Integration' or 'Staging'). Note that the property file may need to be edited (and the moves application restarted). See the section 'Oracle Application Server usernames and passwords' in Moves Property File settings.

Stacks

A Stack is simply a grouping of Applications and Containers by Environment. Stacks allow Moves to answer the question 'What is the container for Application 'X' in Environment 'Y'. Once you create a Stack, you can add containers to it for each environment. When we subsequently configure an application, we will tell it what Stack is associated with that application. (So, for example, the application 'OGS Application' might reference 'OGS Stack'. 'OGS Stack' references containers for 'Production', 'QA', and 'Development'). By looking at these relationships, Moves knows which container to deploy to when asked to deploy to a particular environment.

Containers

A container is the service that an application is deployed to. When you configure a new Container, you will be asked to select from one of the container types. The two container types that are currently available are

• OC4J Container (deploys to Oc4j containers)
• Mock Container (does nothing, used to test workflows)
  In the future we will implement other containers according to MIT needs (tomcat/weblogic etc).

For the Oc4j container, the deployerUrl must be configured. This is the url you would normally type if you are manually deploying an application using the oracle admin_client.jar utility. Typically you will use a deployerUrl of the form deployer:oc4j:opmn://server-name:port-number/application-name for OAS clusters. You will use a deployerUrl of the form deployer:oc4j:localhostserver-name for OAS standalone instances. The deployment process essentially just runs the admin_client program. Below is the configuration page for containers.

Moves will need to know

1. Where is your oc4j home directory (so it can locate the admin_client.jar program)
2. What is the deployer url for the cluster (or standalone instance)
3. What is the username and password to use for the target container

The following checklist should help you successfully configure a container.

1. Start off by making sure you have network access between the Moves Server and the Container you wish to deploy to.

Applications

Applications represent web apps (.war or .ear applications) that can be deployed to a container. (TODO: discuss the optional and required parameters in more detail)

Removing Artifacts

A utility exists within the Moves Application for deleting old Log and File entries. Simply select a date and click submit. Artifacts/Logs older than this date will be removed.