NOTE 8-17-2015
This currently only applies to using Moves with sais-common, and not with csf and beyond
Administering Moves
This page focuses on the Administration section of Moves. To see a description of the startup properties required look at Moves Property File settings.
The entities that need to be administered for moves are listed below.
Table of Contents |
---|
In general you should set entities up in the order that they appear above. The entities are described in detail belowgeneral you should set entities up in the order that they appear above. The entities are described in detail below.
Anchor | ||||
---|---|---|---|---|
|
Application Release Components
(aka "Why doesn't my new app show up in the list of apps on the "Build a Release" page?)
To get your new app to appear in the drop-down list on the "Build a Release" page, it needs to be added to a pom file in the "maven/releases" project in the sais-sis-common repo. The URL is:
svn+ssh://svn.mit.edu/sais-sis-common/maven/releases/trunk/pom.xml
You will need to know:
- The app's maven group id
- The app's maven artifact id
- The URL for the app's trunk in the scm
You will add a "releaseComponent" section under the "releaseComponents" section, that will look like this:
Code Block |
---|
<releaseComponent implementation="edu.mit.maven.plugins.release.common.ReleaseComponent">
<groupId>edu.mit.ist.es.supervasgn</groupId>
<artifactId>assignsupervisor</artifactId>
<scm>
<developerConnection>scm:svn:svn+ssh://svn.mit.edu/sais-sis-academic/academic-supervasgn-web/trunk</developerConnection>
</scm>
</releaseComponent>
|
Check this change in, and the app should now appear in the drop-down list in Moves.
Anchor | ||||
---|---|---|---|---|
|
...
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:
...
Property Name | Description | |
---|---|---|
${groupId} | replaced with the groupId of the application being deployed | |
${artifactId} | replaced with the artifactId of the application being deployed | |
${version} | replaced with the version of the application being deployed <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3dac45fb-962f-479a-9309-d157bb4620a5"><ac:plain-text-body><![CDATA[version of the application being deployed | |
${app.[paramName]} | replaced with the parameter value with key 'paramName' of the application being deployed | ]]></ac:plain-text-body></ac:structured-macro> |
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.
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.
Anchor | ||||
---|---|---|---|---|
|
...
Environments are really just a lookup that identifies the function of containers within a stack. The standard environments are 'Production', 'QAProduction' , and 'DevelopmentTest'. These are already should be automatically set up when Moves is deployed for the first time, 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.
Anchor | ||||
---|---|---|---|---|
|
Stacks
...
- Start off by making sure you have network access between the Moves Server and the Container you wish to deploy to. (For non-local deployments you will need the IS&T infrastructure team to complete these steps).
- open a shell on the machine where Moves is running.
- cd to the ORACLE_HOME folder for this machine (typically /home/oracle/product/10.1.3/j2ee/home)
type *java -jar admin_client.jar \ [deployerUrl] \ [oc4j-admin-username] \ [oc4j-admin-password] -listApplications*. You should see a list of zero or more applications. *You MUST be able to execute this step without getting errors before even bothering returning to Moves!!!* The most common sources of error here are no network connection (firewall or ipconfig issues), bad usernames/passwords, incorrect deployer urls.Wiki Markup - Upon completion of this step, make a note of the deployerUrl, oc4j-admin-username and oc4j-admin-password.
- For the environment type that you will be using, verify that the oracle username and password found in the previous step are correctly set up in the properties file. See Moves Property File settings, specifically the section 'Oracle Application Server usernames and passwords'.
- On the Administration->Stacks->Container page, make sure the environment type is correctly set, and that the deployerUrl matches the previous step.
- Save the container.
Use the Server Test Page! Simply click on the "container ping" icon ( ) for the container you want to test. The page should list the same applications as were listed in the prior step. If the Server Test Page returns an error, go through the steps above again. You will NOT be able to deploy to a container that does not return a successful response on the Server Test Page!Anchor ServerTestPage ServerTestPage
...
- Where maven is located on the system
- Whether to include verbose logging in builds (This should really be moved to the build workflow)
- Where build artifacts are stored
- How long a build should take before we kill it.
- Where the mit maven repository is located (This is duplicated in Admin ->Repositories because the setup for Moves and Maven is quite different)
- The maven goal for releasing an app. This is fully qualified, and contains the groupId, artifactId and version of the plugin. This allows us to "upgrade" the plugin when it has been adequately tested). An example is edu.mit.maven.plugins:mit-release-plugin:1.2.3:release. Usually only the version number will change (in this example the version is 1.2.3).
- The maven goal for populating build drop downs. This is fully qualified, and contains the groupId, artifactId and version of the plugin. This allows us to "upgrade" the plugin when it has been adequately tested). An example is edu.mit.maven.plugins:mit-release-plugin:1.2.3:info. Usually only the version number will change (in this example the version is 1.2.3).unmigrated-wiki-markup
- Maven System Properties. These are passed as -D\[propertName]=\[propertyValue] parameters to Maven. For MIT we need to provide correct values for the java system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword
- Maven System Properties. These are used to set up the shell environment that Maven runs in. Typically this means correctly setting MAVEN_OPTS, JAVA_HOME, M2_HOME, PATH, and the subversion environment variable SVN_SSH. SVN_SSH is used to tell subversion where the public key is to connect over SSH without prompting for a password.
javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword
...