This manual describes how to install and configure Deployit.
This section contains information on the installation of the Deployit server.
To install the Deployit server, the following prerequisites must be met:
Depending on the environment, the following may also be required:
The Deployit server itself only uses about 70MB of disk space. The main harddisk space usage comes from the repository which stores your deployment packages and deployment history. The size of the repository will vary from installation to installation but depends mainly on:
Follow this procedure to obtain an estimate of the total required disk space:
NumPackages)NumDeployments)InitialSize).SizeAfterImport).SizeAfterDeployments).The needed amount of disk space in total is equal to:
Space Needed = ((SizeAfterImport - InitialSize) * NumPackages) +
((SizeAfterDeployments - SizeAfterImport) * NumDeployments)
If NumPackages and NumDeployments are expressed per timeunit (e.g. the number of packages to be imported per month), then the end result represents the space needed per timeunit as well.
Unix-based middleware servers that Deployit interacts with must meet the following requirements:
Defaults requiretty setting in the sudoers file.Credentials: Deployit should be able to log in to the target systems using a login/password combination that allows it to perform at least the following Unix commands:
cplsmvrmmkdirrmdirIf the login user cannot perform these actions, Deployit can also use a sudo user that can execute these commands.
Windows-based middleware servers that Deployit interacts with must meet the following requirements:
It is possible to connect Deployit to middleware servers that do not support SSH, Telnet or WinRM. Using the Overthere remote execution framework, a custom access method can be created that connects to the server. See the Customization Manual for more details.
To use the Deployit GUI, you must meet the following requirements:
To use the Deployit CLI, you must meet the following requirements:
To begin installing Deployit, first unpack the distribution archive. The distribution archive contains the following:
Note: see the separate Upgrade Manual for instructions on how to upgrade Deployit from a previous version.
Follow these steps to install the Deployit server application:
deployit./opt/xebialabs/deployit.Deployit Server Directory Structure
Once the Deployit installation file is extracted, the following directory structure exists in the installation directory (in the remainder of the document this directory will be referred to as DEPLOYIT_SERVER_HOME):
Follow these steps to install the Deployit CLI application:
Deployit CLI Directory Structure
Once the Deployit installation file is extracted, the following directory structure exists in the installation directory:
Run the Deployit Setup Wizard to start the Deployit server and prepare it for use. The command server.sh -setup starts the wizard. If you want to stop the Setup Wizard at any time, enter exitsetup. All changes to the configuration will be discarded.
The Setup Wizard displays the following welcome message:
Welcome to the Deployit setup.
You can always exit by typing 'exitsetup'.
To re-run this setup and make changes to the Deployit server configuration
you can run server.cmd -setup on Windows or server.sh -setup on Unix.
Do you want to use the simple setup?
Default values are used for all properties. To make changes to the default
properties, please answer no.
Options are yes or no.
[yes]:
Answer yes (or press Enter) to use the simple setup. Simple setup makes it easy to quickly get started with Deployit and to use the product's default configuration. See Simple Setup for more information.
Answer no to use the manual setup. Manual setup provides explicit control over all Deployit settings. See Manual Setup for more information.
Note: if you installed Deployit in the same location before, the Setup Wizard will ask you whether you want to edit the existing configuration or create a new one. Answer yes (or press Enter) to edit the existing configuration. The Setup Wizard will load all settings from the existing configuration and allow you to choose simple or manual setup. Answer no to start over with an empty configuration.
Using simple setup, the Setup Wizard will assume default values for all configuration parameters. Specifically, the following defaults will be used:
importablePackages directory.The Setup Wizard will ask one more question:
Do you want Deployit to initialize the JCR repository?
Options are yes or no.
[yes]:
Answer yes (or press Enter) if you want the Deployit repository to be recreated. The Setup Wizard must have write access to the repository directory. Answer no to leave the repository intact. This option is useful if you already have an existing repository that you want to reuse.
See Finishing the Setup Wizard for completing the setup process.
Warning: if you choose to recreate the Deployit repository and you have installed Deployit in the same location before, any information stored in the repository will be lost.
The manual setup procedure contains the following steps:
Secure Communication Configuration
The Setup Wizard will show the following message:
Would you like to enable SSL?
Options are yes or no.
[yes]:
Answer no to use regular unsecured communication between the GUI and the server. Continue with the Http configuration section.
Answer yes (or press Enter) if you want to use a secure connection from the GUI to the server.
If you answer yes, the Setup Wizard will ask the following question to help you configure secure communication:
Would you like Deployit to generate a keystore with a self-signed
certificate for you?
N.B.: Self-signed certificates do not work correctly with some versions
of the Flash Player and some browsers!
Options are yes or no.
[yes]:
Answer yes (or press Enter) if you want the Setup Wizard to generate a digital certificate automatically. The digital certificate is required to secure communication and is normally signed by a Certificate Authority (CA). The Setup Wizard can generate a self-signed certificate if there is no official certificate available. Beware that using a self-signed certificate may trigger security warnings in some Flash players and browsers. Continue with the Http configuration section.
Answer no if you want to use your own keystore. Deployit uses the built-in Jetty webserver to communicate with the GUI. Jetty requires a certificate with the name Jetty to be present in the keystore.
The Setup Wizard prompts you for the following keystore information:
What is the path to the keystore?
[]:
What is the password to the keystore?
[]:
What is the password to the key in the keystore?
[]:
Enter the filesystem location of the keystore (for example, mykeystore.jks), the password to unlock the keystore and the password for the Jetty certificate in the keystore.
Http Configuration
The Setup Wizard shows the following questions:
What http bind address would you like the server to listen on?
[localhost]:
What http port number would you like the server to listen on?
[4516]:
Enter the web context root where Deployit will run
[/]:
Note: if you chose to enable secure communication, the default port will be 4517 instead of 4516.
Enter the host name, port number and context root that the Deployit server listens on for connections.
Thread Configuration
The Setup Wizard shows the following questions:
Enter the minimum number of threads the HTTP server should use (recommended:
3 per client, so 3 for single user usage)
[3]:
Enter the minimum number of threads that the Deployit server uses to handle incoming connections. The recommended minimum number of threads is 3 per Deployit application client.
Enter the maximum number of threads the HTTP server should use (recommended :
3 per client, so 24 for 8 concurrent users)
[24]:
Enter the maximum number of threads that the Deployit server uses to handle incoming connections. The recommended maximum number of threads is 3 per Deployit application client.
Repository Configuration
The Setup Wizard shows the following questions:
Where would you like Deployit to store the JCR repository?
[repository]:
Enter the filesystem path to a directory where Deployit will create the repository. If the directory does not exist, the Setup Wizard will create it.
Do you want Deployit to initialize the JCR repository?
Options are yes or no.
[yes]:
Answer yes (or press Enter) if you want the Deployit repository to be recreated. The Setup Wizard must have write access to the repository directory.
Answer no to leave the repository intact.
Warning: if you choose to recreate the Deployit repository and you have installed Deployit in the same location before, any information stored in the repository will be lost.
Importable Packages Configuration
The Setup Wizard shows the following question:
Where would you like Deployit to import packages from?
[importablePackages]:
Enter the filesystem path to a directory from which Deployit will import packages. The Setup Wizard assumes that this directory exists once the Deployit server starts and will not create it.
Once you have completed configuration of the setup process, the Setup Wizard displays an overview of all selected options. The following text is an example:
Do you agree with the following settings for Deployit and would you like
to save them?
Changes will be saved in deployit.conf
SSL will be disabled
HTTP bind address is localhost
HTTP port is 4516
HTTP server will use a minimum of 3 and a maximum of 24 threads
JCR repository home is at repository
JCR repository will be initialized.
Task recovery file will deleted
Application import location is importablePackages
[yes]:
Answer yes (or press Enter) to store the configuration settings and end the Setup Wizard. If you selected the option to initialize the repository, this will be done now.
Answer no to abort the Setup Wizard.
If the Setup Wizard is successfully completed, it will display the following message:
You can now start your Deployit server by executing the command server.cmd
on Windows or server.sh on Unix.
Note: If your Deployit server is running please restart it.
Finished setup.
By default, Deployit is installed with a special user with administrative permissions. This user has the username admin and password admin. As the last step in the installation, the admin password should be changed to something more secure. Issue the following commands in the CLI to do this:
adminUser = security.readUser('admin')
adminUser.password = 'newpassword'
security.modifyUser(adminUser)
# Test whether the change is successful
security.logout()
security.login('admin', 'newpassword')
The admin password must also be set in the deployit.conf file in the conf directory in the server installation directory so that Deployit can access the repository with administrative permissions.
After changing the password in the repository, stop the server and edit the deployit.conf file. When the server starts up again, it will read the new administrative password and encrypt it so that it is unreadable in the deployit.conf file.
Deployit can be configured to ensure maximum uptime of the application. In such a high availability setup, two instances of Deployit are running in an active/passive configuration. At any one time, only one Deployit instance is active but as soon as a failure is detected, the passive Deployit instance is activated and the failed instance is taken down for repair.
To configure Deployit for high availability, the Deployit repository must be used in clustering mode. This means that each Deployit node writes changes to a shared journal in addition to applying the change to it's own repository. See the section Configuring the Repository below for more information on setting up clustering.
This section contains information on the configuration of the Deployit server.
See the separate Security Manual for more information about how to configure security.
By default, Deployit authenticates users and retrieves authorization information from it's repository. Deployit can also be configured to use an LDAP repository to authenticate users and to retrieve role (group) membership. In this scenario, the LDAP users and groups are used as principals in Deployit and can be mapped to Deployit roles. Role membership and rights assigned to roles are always stored in the JCR repository.
Deployit treats the LDAP repository as read-only. This means that Deployit will use the information from the LDAP repository, but can not make changes to that information.
To configure Deployit to use an LDAP repository, the security configuration file deployit-security.xml must be modified. This is an example of a working deployit-security.xml file that uses LDAP:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd
">
<security:ldap-server id="ldapServer" url="ldap://localhost:389/" root="ou=system"
manager-dn="cn=admin,dc=example,dc=com" manager-password="secret"/>
<security:authentication-manager alias="authenticationManager">
<security:authentication-provider ref="rememberMeAuthenticationProvider" />
<security:ldap-authentication-provider server-ref="ldapServer"
user-search-filter="(&(uid={0})(objectClass=inetOrgPerson))"
user-search-base="dc=example,dc=com"
group-search-filter="(memberUid={0})"
group-search-base="ou=groups,dc=example,dc=com"
/>
<security:authentication-provider ref="deployitAuthenticationProvider"/>
</security:authentication-manager>
<bean id="deployitAuthenticationProvider"
class="com.xebialabs.deployit.security.authentication.JcrAuthenticationProvider"/>
<bean id="rememberMeAuthenticationProvider"
class="com.xebialabs.deployit.security.authentication.RememberMeAuthenticationProvider"/>
</beans>
These options can be specified for the ldap-server element:
These options can be specified for the ldap-authentication-provider element:
{0} will be replaced with the username that's logging in (example: user-search-filter="(&(uid={0})(objectClass=inetOrgPerson))"){0} will be replaced with the DN of the user (example: group-search-filter="(memberUid={0})")Deployit server will need to be restarted after you have configured LDAP access.
Deployit uses a repository to store all of it's data such as CIs, deployment packages, logging, etc. Deployit can use the filesystem or a database for binary artifacts (deployment packages) and CIs and CI history.
Out of the box, Deployit uses the filesystem to store all data in the repository.
Deployit can also use a database to store its repository. The built-in Jackrabit JCR implementation must be configured to make this possible.
There are several configuration options when setting up a database repository: * Store only binary artifacts in a database. This requires configuring the DataStore property. * Store only CIs and CI history in a database. This requires configuring the PersistenceManager and FileSystem properties. * Store all data (binary artifacts and CIs and CI history) in a database. This requires configuring the DataStore, PersistenceManager and FileSystem must be configured.
Here are some examples of configuring Deployit to use a database for various database vendors. The XML snippets below must be put into the conf/jackrabbit-repository.xml file.
Note: Deployit must initialize the repository before it can be used. Run Deployit's setup wizard and initialize the repository after making any changes to the repository configuration.
For more information about using a database with Jackrabbit, see it's PersistenceManager FAQ and DataStore FAQ.
Using Deployit with MySQL
<DataStore class="org.apache.jackrabbit.core.data.db.DbDataStore">
<param name="driver" value="com.mysql.jdbc.Driver"/>
<param name="url" value="jdbc:mysql://localhost:3306/deployit"/>
<param name="databaseType" value="mysql"/>
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</DataStore>
<Workspace name="${wsp.name}">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="com.mysql.jdbc.Driver"/>
<param name="url" value="jdbc:mysql://localhost:3306/deployit"/>
<param name="schemaObjectPrefix" value="${wsp.name}_" />
<param name="schema" value="mysql" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManagerr class="org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager">
<param name="driver" value="com.mysql.jdbc.Driver"/>
<param name="url" value="jdbc:mysql://localhost:3306/deployit" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="schemaObjectPrefix" value="${wsp.name}_" />
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index" />
<param name="supportHighlighting" value="true" />
</SearchIndex>
</Workspace>
<Versioning rootPath="${rep.home}/version">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="com.mysql.jdbc.Driver"/>
<param name="url" value="jdbc:mysql://localhost:3306/deployit"/>
<param name="schemaObjectPrefix" value="version_" />
<param name="schema" value="mysql" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.MySqlPersistenceManager">
<param name="url" value="jdbc:mysql://localhost:3306/deployit" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="schemaObjectPrefix" value="version_" />
</PersistenceManager>
</Versioning>
Note: The MySQL database is not suited for storage of large binary objects, see the MySQL bug tracker.
Using Deployit with DB2
<DataStore class="org.apache.jackrabbit.core.data.db.DbDataStore">
<param name="driver" value="com.ibm.db2.jcc.DB2Driver"/>
<param name="url" value="jdbc:db2://localhost:50002/deployit"/>
<param name="databaseType" value="db2"/>
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</DataStore>
<Workspace name="${wsp.name}">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="com.ibm.db2.jcc.DB2Driver"/>
<param name="url" value="jdbc:db2://localhost:50002/deployit"/>
<param name="schemaObjectPrefix" value="${wsp.name}_" />
<param name="schema" value="db2" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager">
<param name="driver" value="com.ibm.db2.jcc.DB2Driver"/>
<param name="url" value="jdbc:db2://localhost:50002/deployit" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="databaseType" value="db2" />
<param name="schemaObjectPrefix" value="${wsp.name}_" />
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index" />
<param name="supportHighlighting" value="true" />
</SearchIndex>
</Workspace>
<Versioning rootPath="${rep.home}/version">
<FileSystem class="org.apache.jackrabbit.core.fs.db.DbFileSystem">
<param name="driver" value="com.ibm.db2.jcc.DB2Driver"/>
<param name="url" value="jdbc:db2://localhost:50002/deployit"/>
<param name="schemaObjectPrefix" value="version_" />
<param name="schema" value="db2" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager">
<param name="driver" value="com.ibm.db2.jcc.DB2Driver"/>
<param name="url" value="jdbc:db2://localhost:50002/deployit" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="databaseType" value="db2" />
<param name="schemaObjectPrefix" value="version_" />
</PersistenceManager>
</Versioning>
Using Deployit with Oracle
<DataStore class="org.apache.jackrabbit.core.data.db.DbDataStore">
<param name="driver" value="oracle.jdbc.OracleDriver"/>
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<param name="databaseType" value="oracle"/>
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</DataStore>
<Workspace name="${wsp.name}">
<FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
<param name="driver" value="oracle.jdbc.OracleDriver"/>
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
<param name="schema" value="oracle" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager">
<param name="driver" value="oracle.jdbc.driver.OracleDriver"/>
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="databaseType" value="oracle" />
<param name="schemaObjectPrefix" value="${wsp.name}_" />
</PersistenceManager>
<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
<param name="path" value="${wsp.home}/index" />
<param name="supportHighlighting" value="true" />
</SearchIndex>
</Workspace>
<Versioning rootPath="${rep.home}/version">
<FileSystem class="org.apache.jackrabbit.core.fs.db.OracleFileSystem">
<param name="driver" value="oracle.jdbc.OracleDriver"/>
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<param name="schemaObjectPrefix" value="version_"/>
<param name="schema" value="oracle" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager">
<param name="driver" value="oracle.jdbc.driver.OracleDriver"/>
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl"/>
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="databaseType" value="oracle" />
<param name="schemaObjectPrefix" value="version_" />
</PersistenceManager>
</Versioning>
If you use the TNSNames Alias syntax to connect to Oracle, you may need to inform the driver where to find the TNSNAMES file. See the Oracle documentation for more details.
It is also possible to run Deployit server with its repository shared with other Deployit server instances. For this to happen, the jackrabbit JCR must be configured to run in a clustered mode. This needs a cluster configuration to be present in the jackrabbit-repository.xml file.
File-based repository
Add the following snippet to the jackrabbit-repository.xml to enable clustering:
<Cluster id="node1">
<Journal class="org.apache.jackrabbit.core.journal.FileJournal">
<param name="revision" value="${rep.home}/revision.log" />
<param name="directory" value="/nfs/myserver/myjournal" />
</Journal>
</Cluster>
In the above example, the property directory refers to the shared journal. Both Deployit instances must be able to write to the same journal.
Database repository
The following XML snippet shows a sample clustering configuration for a JCR using Oracle as its repository.
<Cluster id="101" syncDelay="2000">
<Journal class="org.apache.jackrabbit.core.journal.OracleDatabaseJournal">
<param name="revision" value="${rep.home}/revision" />
<param name="driver" value="oracle.jdbc.driver.OracleDriver" />
<param name="url" value="jdbc:oracle:thin:@localhost:1521:orcl" />
<param name="user" value="deployit" />
<param name="password" value="deployit" />
<param name="schemaObjectPrefix" value="JOURNAL_" />
</Journal>
</Cluster>
Note that each jackrabbit cluster node should have a unique value for id. For more information on JCR clustering, or ways to configure clustering using other databases, please refer to the jackrabbit clustering documentation.
Deployit Server supports various plugins that add functionality to the system. When it starts, the Deployit server scans the plugins directory and loads all plugins it finds. The additional functionality they provide is immediately available. Any plugins added or removed when Deployit server is running will not take effect until the server is restarted.
Installing a Plugin
To install a new plugin, stop the Deployit server and copy the plugin JAR archive into the plugins directory, then restart the Deployit server.
Uninstalling a Plugin
To uninstall a plugin, stop the Deployit server and remove the plugin JAR archive from the plugins directory, then restart the Deployit server.
Out of the box, Deployit server writes informational, warning and error log messages to standard output as well as log/deployit.log when running. It is possible to change this behavior to write log output to a file or to log output from a specific source.
Deployit uses the Logback logging framework for it's logging. To change it's behavior, edit the file logback.xml in the conf directory of the Deployit server installation directory.
The following is an example logback.xml file:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>
%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
</pattern>
</encoder>
</appender>
<!-- Create a file appender that writes log messages to a file -->
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>%-4relative [%thread] %-5level %class - %msg%n</pattern>
</layout>
<File>log/my.log</File>
</appender>
<!-- Set logging of classes in com.xebialabs to DEBUG level -->
<logger name="com.xebialabs" level="debug"/>
<!-- Set logging of class HttpClient to DEBUG level -->
<logger name="HttpClient" level="debug"/>
<!-- Set the logging of all other classes to INFO -->
<root level="info">
<!-- Write logging to STDOUT and FILE appenders -->
<appender-ref ref="STDOUT" />
<appender-ref ref="FILE" />
</root>
</configuration>
For more information see the Logback website.
A number of advanced configuration options are available by editing the deployit.conf file in the conf directory. Restart the server after making the necessary changes.
Starting the Server
Open a terminal window and change to the DEPLOYIT_SERVER_HOME directory. Start the Deployit server with the command:
bin/server.sh
on Unix and
bin/server.cmd
on Windows.
By starting the server with the -h flag, a message is printed that shows the possible options it supports:
server.sh arguments...
-reinitialize : Reinitialize the repository, only useful with -setup
-setup : (Re-)run the setup for Deployit
The command line options are:
-reinitialize -- tells Deployit to reinitialize the repository. Used only in conjunction with -setup. N.B. This flag only works if Deployit is running on the filesystem repository, not when you've configured Deployit to run against a database.-setup -- runs the Deployit Setup Wizard.-test-mode -- enables Deployit server test-mode. When test-mode is enabled, WebDAV access to the JCR repository is installed. The repository can be accessed using a URL like http://localhost:4516/repository/default/.Server Options
Any options you want to give the Deployit Server when it starts can be specified in the DEPLOYIT_SERVER_OPTS environment variable.
Starting Deployit in the Background
By running the server.sh or server.cmd command, the Deployit server is started in the foreground. To run the server as a background process, use:
nohup bin/server.sh &
on Unix or run Deployit as a service on Windows.
Stopping the Server
It is possible to stop the Deployit server using a REST API call. The following is an example of a command to generate such a call (replace admin:admin with your own credentials):
curl -X POST --basic -u admin:admin
http://admin:admin@localhost:4516/deployit/server/shutdown
This requires the external curl command, available for both Unix and Windows. The server can also be shutdown using the CLI.
This section describes how to maintain the Deployit server in your environment.
To create a backup of Deployit, several components may need to be backed up depending on your configuration:
repository directory.repository directory, as well as the database (using the tools provided by your database vendor).conf directory in the installation directory.ext and plugins directory in the installation directory.Note: Deployit must not be running when you are making a backup. Schedule backups outside planned deployment hours to ensure the server is not being used.
To restore a backup of Deployit, restore one of the following components:
repository directory and replace it with the backup.repository directory and replace it with the backup. Next, restore a backup of the database using the tools provided by your vendor.conf directory in the DEPLOYIT_SERVER_HOME directory and replace it with the backup.ext and plugins directories in the DEPLOYIT_SERVER_HOME directory and replace them with the backups.Note: Deployit must not be running when you are restoring a backup.
The repository is the place where Deployit stores all of it's data. If you deal with lots of large binary artifacts, this can be problematic since the disk space they consume is not reclaimed when the are deleted. To reclaim the disk space after deleting a CI, use the following CLI snippet:
deployit.runGarbageCollector()