Introduction
This document describes the main steps to setup the infrastructure of a continuous integration environment, which also can be used for subsequent deployment processes in the overall continuous delivery process.Note
This cookbook requires Intershop build and deployment tools version 1.x.
How deal with the Intershop build and deployment tools 2.0 until 2.1 is described here: Cookbook - Setup of CI Infrastructure (valid to GradleTools 2.1).
The according cookbook for the Intershop build and deployment tools 2.3 and later can be found here: Cookbook - Setup of CI Infrastructure (valid to Gradle Tools 2.3).
The according cookbook for the Intershop build and deployment tools 2.7 and later can be found here: Cookbook - Setup CI Infrastructure (valid to Gradle Tools 2.7).
The overview diagram shows the required systems for the setup process and the final distribution of software artifacts after the execution of all these steps. It is possible to use a CI server for the automatic execution of some steps.
Note
The recipes in this cookbook are made for a specific ICM version in combination with specific Intershop Gradle Tools.
Since the bootstrap of the Intershop Gradle Tools defines your project's directory structure and different versions of the Intershop Gradle Tools differ regarding their plugins you have to ensure to use a valid combination of ICM and Intershop Gradle Tools.
For detailed version dependency information refer to Reference - CI Dependencies of Intershop Commerce Management.
For more detailed information on which plugins are available/deprecated for which Intershop Gradle Tools version refer to:
Glossary
| Phrase | Meaning |
|---|---|
| Version Control System (VCS) | Also known as source control, source code management systems (SCM), or revision control systems (RCS). VCS is a mechanism for keeping multiple versions of your files, so that when you modify a file you can still access the previous revisions. |
| Artifact Repository | Place, where build and package software components are located. Provide a common interface to a dependency management system. |
| Code Analysis | Process to analyze source code to calculate metrics, find bugs, etc. |
| Continuous Delivery Pipeline | Sometimes called Deployment Pipeline, describes the stages, which code artifacts runs through source to production system. |
| System Component | A software package of different code artifacts and files, that have to be deployed together. |
| System Component Set | Is a container for system components, that needs to be build and branched together. |
| Assembly | An assembly references one or more system components residing in the same or a configured artifact repository in order to deploy or deliver them together. |
| Build Process | Compiles and packages files and code artifacts from a source project to deployable artifacts. |
| Publish Process | The process which transfers the deployable artifacts to a configured artifact repository. |
| Assembly Process | This process combines several system components to an assembly. |
| Deployment Process | This process extracts files and code artifacts from an artifact repository and applies the configuration. |
| Project Gradle Distribution | This is a customized Gradle distribution with the preconfigured artifact repositories and Gradle plugins. |
| Gradle Plugin | A Gradle plugin packages up reusable pieces of build logic, which can be used across many different projects and builds. |
| Project Gradle Plugin | This is a Gradle plugin which contains special corporate respectively project settings. |
| Corporate Plugin | The term is used as a synonym for Project Gradle Plugin. |
| Gradle Extension Object | Java Bean compliant class holding configurations for Gradle plugins. |
| Gradle Wrapper | The Gradle Wrapper is the preferred way of starting a Gradle build. The wrapper is a batch script on Windows, and a shell script for other operating systems. When you start a Gradle build via the wrapper, Gradle will be automatically downloaded and used to run the build. See for more information The Gradle Wrapper in the Gradle documentation (2.11, 2.7, 2.3, 2.0, 1.8) |
| Intershop Cluster | A number of hosts of different types serving an Intershop 7. |
| Cluster Node | One separately deployable part of an Intershop cluster. A host can run multiple nodes of one Intershop cluster. |
References
Recipe: Configure the Artifact Repository Server
Problem
The artifact repository server in the continuous integration environment is necessary to server built artifacts to development environment as well as the build server. The build engineer respectively developer should setup and configure this server in the beginning of a project. Which artifact repository server are available and which configuration is required to run the Intershop build, assembly and deployment tools?
Solution
Following artifact repository servers are available and work with the Intershop continuous delivery tools:
The documentation is using always the Nexus from Sonatype. Therefore, all paths and configurations are special for this kind of repository. It is also possible to use other repositories. Paths and configurations has to be similar to this special configurations.
It is possible to use the use the Nexus Repository Manager provided by Sonatype.org.
| URL | http://www.sonatype.org/ |
| Download URL | |
| Install documentation | https://support.sonatype.com/forums/22202613-Getting-Started |
It is necessary to install the software of a repository before you can implement the following settings.
This is the overview of available repositories in a base installation before any changes:
The following repositories are necessary for all build and deployment processes:
Proxy Repositories
| Name | ID | Repostiory Type | Remote Storage Location |
|---|---|---|---|
| Central | central | Proxy | http://repo1.maven.org/maven2/ |
If you need additional remote repositories, all these repositories should be configured in one group. This makes it easier to configure this kind of repositories in the Gradle configuration, because all different repositories are usable over one URL: This repositories provide third party artifacts from public Maven repositories. The repository needs an access to the internet!
Hosted Repositories
| Name | ID | Repository Type | Repository Policy | Deployment Policy | Usage |
|---|---|---|---|---|---|
| Distributions | distributions | hosted | Release | Disable Redeploy | for project Gradle distribution |
| Gradle | gradle | hosted | Release | Disable Redeploy | for project Gradle plugins |
| Releases | releases | hosted | Release | Disable Redeploy | for all released artifacts of Intershop and also your own releases |
| Snapshots | snapshots | hosted | Snapshot | Allow Redeploy | for all artifacts from snapshot builds |
Summary
The format of all hosted and proxy repositories is always Maven 2. The ID is case sensitive, because this part of the URL.
It is necessary to configure these repositories in your artifact repository installation. After the configuration the following URLs is available:
| Name | URL |
|---|---|
| Central | http://<Hostname:Port>/nexus/content/repositories/central |
| Distributions | http://<Hostname:Port>/nexus/content/repositories/distributions |
| Gradle | http://<Hostname:Port>/nexus/content/repositories/gradle |
| Releases | http://<Hostname:Port>/nexus/content/repositories/releases |
| Snapshots | http://<Hostname:Port>/nexus/content/repositories/snapshots |
This is the overview after these changes:
Discussion
It is possible to use a group configuration for some repositories. This solution describes a minimum setup which is also used for the following steps and recipes.
Furthermore it is possible an other repository.
Recipe: Set Up a Project Environment in the Artifact Repository
Problem
For the project setup it is necessary to create some source artifacts and of course the binary representation, which are used for shared development in a team.
- Project Gradle Plugin
This plugin configures settings for the used repositories - URLs and Ivy patterns. This plugin helps to provide the same configuration for all steps in the project live cycle. - Project Gradle Distribution
This is a distribution of Gradle extended with an init script. This init script injects the plugin for version handling as well as the Project Gradle Plugin which is responsible for the repository handling. - Configuration for import of a specific Intershop delivery
It is necessary to import a Intershop delivery with all components to the artifact repository. Intershop provides an script for this import task. The task needs a configuration file import.properties. - Developer Configuration
A developer needs some configuration files for their daily work. These configuration files can be project specific, environment specific as well user specific. They also contain environment scripts that allow to work with different development contexts, like branches, on the same development machine. - Base Component Set
The development of Intershop components is based on component sets. A normal project needs one component set. Components / cartridges are stored in this component sets. A component set is a multi project in Gradle (see Chapter 56. Multi-project Builds). This source artifact contains basically all extensions and adaptions for Intershop.
For larger projects it is possible to split all project cartridges in different component sets. - Assembly
An assembly is created from different cartridges of the base Intershop product and from the project. It contains also special settings for the deployment in different environments. This is an other necessary source project for an customized Intershop installation.
It is necessary to store these sources in well structured in a source code management server like SVN or GIT.
How can an build engineer or specialized developer prepare these source artifacts?
Solution
Intershop provides a set of a templates which can be used to set up a structure with all the described source artifacts.
Prerequisites
This describes the minimum requirements
- Prepared the artifact repository (see Recipe: Configure the Artifact Repository Server)
- Intershop delivery package of a special version, eg Intershop-7.4.6.0.20140302004212.zip
- Local Windows or Linux machine with
- installed Oracle JDK 1.7.0_51 or higher
- access to http://services.gradle.org/distributions/gradle-1.8-bin.zip
- access to the artifact repository
- access to the VCS
- Oracle JDBC driver libraries ( ojdbc6.jar, ucp.jar)
Steps
Unpack the Delivery Package to a Local File System
| Working directory | <special directory with Intershop-<version>.zip> |
| Command | unzip Intershop-<version>.zip |
| Size | 2.5GB |
<folder>
| Intershop-<version>.zip
|
\---Intershop-<version>
| build.gradle
| gradlew
| gradlew.bat
| Readme
|
+---deploy.sample
| settings.gradle
|
+---development-setup
| | build.gradle
| | configuration.gradle
| | Readme
| |
| \---templates
| +---assembly
| |
| +---componentset
| |
| +---corporate-distribution-packager
| |
| +---corporate-plugins
| |
| +---custom-fix
| |
| +---deployment_demoserver
| |
| +---deployment_intershopdemo
| |
| +---gradle_user_home
| |
| \---import
|
+---gradle-1.8
|
+---gradle-home
|
+---import
| import.properties
| Readme
| settings.gradle
|
+---oracle-jars
|
\---repositories
| version.properties
|
\---components
Provide Oracle JDBC Driver Files
Manually c opy the Oracle JDBC driver libraries to the prepared folder oracle-jars as first step
<folder>
| Intershop-7.4.6.0.20140302004212.zip
|
\---Intershop-7.4.6.0.20140302004212
| build.gradle
| gradlew
| gradlew.bat
| Readme
|
.
.
.
+---import
| import.properties
| Readme
| settings.gradle
|
+---oracle-jars
| ojdbc6.jar <--
| ucp.jar <--
|
\---repositories
| version.properties
|
\---components
Next execute the gradle copy script for Oracle JDBC libraries.
| Working directory | Intershop-<version> |
| Command (Windows) | gradlew.bat copyOracleJars
|
| Command (Linux) | ./gradlew copyOracleJars |
Output example:
<folder>
| Intershop-7.4.6.0.20140302004212.zip
|
\---Intershop-7.4.6.0.20140302004212
| build.gradle
| gradlew
| gradlew.bat
| Readme
|
.
.
.
|
+---oracle-jars
| ojdbc6.jar
| ucp.jar
|
\---repositories
| version.properties
|
\---components
|
\---com.intershop
|
+---3rd_oracle
\---11.2.0.3.0.2
+---ivys
| ivy.xml
| ivy.xml.sha1
|
+---jars
| ojdbc6-jar.jar <--
| ucp-jar.jar <--
|
\---zips
3rd_oracle-share.zip
3rd_oracle-share.zip.sha1
Configuration for Source Artifact Creation
<folder>
| Intershop-7.4.6.0.20140302004212.zip
|
\---Intershop-7.4.6.0.20140302004212
| build.gradle
. gradlew
. gradlew.bat
. Readme
|
+---development-setup
. | build.gradle
. | configuration.gradle <--
. | Readme
|
\---templates
+---assembly
|
+---componentset
|
+---corporate-distribution-packager
|
+---corporate-plugins
|
+---custom-fix
|
+---deployment_demoserver
|
+---deployment_intershopdemo
|
+---gradle_user_home
|
\---import
ext {
/**
* Source dirs for all setup tasks
**/
IntershopCDToolsSetupDir = 'ishCDTools'
...
/**
* Entrprise, corporate or project name
* This is used for some log output in the
* gradle-corporate-plugin
* corporate-plugins/gradle-corporate-plugin/src/main/groovy/com/intershop/build/IntershopRepoDefinitions.groovy
**/
CorporateName = 'Example Corporate Name'
...
/**
* Repo Settings
* Please see 'Configure an Artifact Repository' in the documentation.
* This values are used in
* corpororate-distribution-packager
* build.gradle
* src/init.d/intershop-init.gradle
* corporate-plugins/gradle-corporate-plugin
* build.gradle
* gradle-corporate-plugin
* corporate-plugins/gradle-corporate-plugin/src/main/groovy/com/intershop/build/IntershopRepoDefinitions.groovy
**/
RepoBaseURL = 'http://documentation:8081/nexus'
RepoPathAllRepositories = 'content/repositories'
RepoDistributionsID = 'distributions'
RepoReleasesID = 'releases'
RepoSnapshots = 'snapshots'
RepoCentralID = 'central'
RepoGradleID = 'gradle'
...
/**
* Cartridge development configuration
**/
ComponentGroup = 'com.corporatename'
ComponentSetName = 'a_exampleset'
ComponentSetGroup = 'com.corporatename.set'
ComponentSetVersion = '1.0.0.0'
ProductName = 'Example Corporate Shop'
ProductCorpyrightOwner = 'Corporate Ltd'
ProductCopyrightFrom = '2014'
ComponentName = 'cpt_example'
ComponentDisplayName = 'Example Project Cartridge'
ComponentDescription = 'Example Project Cartridge Description'
/**
* Assembly development configuration
**/
AssemblyName = 'assembly_shop'
AssemblyGroup = 'com.corporatename.assembly'
/**
* Used product version
**/
IntershopProductVersion = '7.4.6.0.20140302004212'
/**
* Used solr version
**/
IntershopSolrServiceVersion = '2.0.11.0.20140219172239'
/**
* Used build plugin versions
**/
CartridgePluginsVersion = '1.0.0.0.+'
ExtensionPluginsVersion = '1.0.0.0.+'
}
| Rows | Addional comments |
|---|---|
| 6 | This is the base directory for all source artifacts. |
| 28 - 34 | This is the repository configuration. |
| 39 - 48 | This is the configuration of a component set a_exampleset with one cartridge cpt_example. Do not use '.' in the name, because this character is used for separation in the repository. |
| 52 - 53 | This is the configuration of the assemply assembly-shop. Do not use '.' in the name, because this character is used for separation in the repository. |
| 57 | The version of Intershop components. It is possible to replace this with an expression, e.g., 7.4.6.+. |
| 61 | The version of the delivered special Solr service of Intershop. |
| 65-66 | The version of Intershop build plugins used in component set and assembly. |
Execute the script to create the source artifacts.
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat setupAll |
| Command (Linux) | ../gradlew setupAll |
Output example
<folder>
| Intershop-7.4.6.0.20140302004212.zip
|
\---Intershop-7.4.6.0.20140302004212
| build.gradle
| gradlew
| gradlew.bat
| Readme
|
+---.gradle
|
+---deploy.sample
| settings.gradle
|
+---development-setup
| | build.gradle
. | configuration.gradle
. | Readme
. |
+---.gradle
|
+---ishCDTools
| +---assemblies
| | \---assembly_shop
| | | build.gradle
| | | cartridge-order.txt
| | | deploy-settings.gradle
| | | deploy.gradle
| | | gradle.properties
| | | gradlew
| | | gradlew.bat
| | | settings.gradle
| | | settings.gradle.tpl
| | |
| | \---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| |
| +---componentsets
| | \---a_exampleset
| | | build.gradle
| | | gradle.properties
| | | gradlew
| | | gradlew.bat
| | | settings.gradle
| | |
| | +---cpt_example
| | | | .classpath
| | | | .project
| | | | build.gradle
| | | |
| | | +---.settings
| | | | \---gradle
| | | | org.springsource.ide.eclipse.gradle.core.prefs
| | | |
| | | \---staticfiles
| | | +---cartridge
| | | | +---components
| | | | | app-extension.component
| | | | |
| | | | +---localizations
| | | | | apps_de.properties
| | | | | apps_en.properties
| | | | |
| | | | +---pipelines
| | | | | pipelines-acl.properties
| | | | | ViewApps-en_US.xml
| | | | | ViewApps.xml
| | | | |
| | | | \---templates
| | | | \---default
| | | | \---application
| | | | IncludeApps.isml
| | | | SiteNavigationBar.isml
| | | |
| | | \---share
| | | \---system
| | | \---config
| | | \---cartridges
| | | cpt_example_demo.properties
| | |
| | \---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| +---custom-fix
| | | Readme
| | |
| | +---builder
| | | | build.gradle
| | | | gradle.properties
| | | | gradlew
| | | | gradlew.bat
| | | | run.bat
| | | | run.sh
| | | |
| | | +---artifacts
| | | | \---example
| | | | deploy.gradle
| | | | lib.jar
| | | | share.zip
| | | |
| | | \---gradle
| | | \---wrapper
| | | gradle-wrapper.jar
| | | gradle-wrapper.properties
| | |
| | +---exporter
| | | build.gradle
| | | gradle.properties
| | | run.bat
| | | run.sh
| | | transfer.gradle
| | |
| | +---home-builder
| | | gradle.properties
| | | init.gradle
| | |
| | +---home-expimp
| | | gradle.properties
| | | init.gradle
| | |
| | \---importer
| | | build.gradle
| | | import.gradle
| | | import.properties
| | | run.bat
| | | run.sh
| | |
| | +---artifacts
| | \---repository
| |
| +---deployment-configurations
| | +---deployment_demoserver
| | | | gradlew
| | | | gradlew.bat
| | | | settings.gradle
| | | |
| | | \---gradle
| | | \---wrapper
| | | gradle-wrapper.jar
| | | gradle-wrapper.properties
| | |
| | \---deployment_intershopdemo
| | | gradlew
| | | gradlew.bat
| | | settings.gradle
| | |
| | \---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| |
| +---distributions
| | \---corporate-distribution-packager
| | | build.gradle
| | | gradle.properties
| | | gradlew
| | | gradlew.bat
| | |
| | +---gradle
| | | \---wrapper
| | | gradle-wrapper.jar
| | | gradle-wrapper.properties
| | |
| | \---src
| | \---init.d
| | intershop-init.gradle
| |
| +---gradle_user_home
| | gradle_environment.bat
| | gradle_environment.sh
| |
| +---import
| | import.properties
| |
| \---plugins
| \---corporate-plugins
| | build.gradle
| | gradle.properties
| | gradlew
| | gradlew.bat
| | settings.gradle
| |
| +---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| |
| \---gradle-corporate-plugin
| \---src
| +---main
| | +---groovy
| | | \---com
| | | \---intershop
| | | \---build
| | | | IntershopRepoDefinitions.groovy
| | | |
| | | \---plugins
| | | | IntershopGradlePlugin.groovy
| | | | IntershopPlugin.groovy
| | | |
| | | +---extension
| | | | IntershopGradleRepos.groovy
| | | | IntershopRepoDefinitions.groovy
| | | | IntershopRepos.groovy
| | | |
| | | \---util
| | | IntershopBuildScript.groovy
| | | IntershopPublishing.groovy
| | |
| | \---resources
| | \---META-INF
| | \---gradle-plugins
| | corporate.properties
| |
| \---test
| +---groovy
| \---resources
\---templates
|
+---assembly
|
+---componentset
|
+---corporate-distribution-packager
|
+---corporate-plugins
|
+---custom-fix
|
+---deployment_demoserver
|
+---deployment_intershopdemo
|
+---gradle_user_home
|
\---import
- The folder ishCDTools contains all necessary files, created by the script from the provided templates.
- The folder componentsets contains component sets of a project
- The folder assemblies contains assemblies of a project.
- The folder custom-fix contains some scripts and tools for custom-fix handling. See Cookbook - Custom Fix Recipes (valid to 7.4 CI)
- The folder deployment-configurations contains configuration examples for different deployments
deployment_demoserver is a configuration on a Linux machine with a local Oracle XE installation for the custom assembly
deployment_intershopdemo is a configuration on a Windows machine for the Intershop demo assembly
- The folder plugins contains all multi projects of Gradle plugins in a project.
- The folder distributions contains all projects of custom distribution of a project.
- The folder gradle_user_home contains developer configuration.
Store the Created Source Artifacts in the VCS
This is an example for a structure in a Subversion repository:
+---assemblies
| |
| \---assembly_shop
| |
| \---trunk
| | build.gradle
| | cartridge-order.txt
| | deploy-settings.gradle
| | deploy.gradle
| | gradle.properties
| | gradlew
| | gradlew.bat
| | settings.gradle
| | settings.gradle.tpl
| |
| \---gradle
| \---wrapper
| gradle-wrapper.jar
| gradle-wrapper.properties
|
+---componentsets
| |
| \---a_exampleset
| |
| \---trunk
| | build.gradle
| | gradle.properties
| | gradlew
| | gradlew.bat
| | settings.gradle
| |
| +---cpt_example
| | | .classpath
| | | .project
| | | build.gradle
| | |
| | +---.settings
| | | \---gradle
| | |
| | \---staticfiles
| | +---cartridge
| | | +---components
| | | | app-extension.component
| | | |
| | | +---localizations
| | | | apps_de.properties
| | | | apps_en.properties
| | | |
| | | +---pipelines
| | | | pipelines-acl.properties
| | | | ViewApps-en_US.xml
| | | | ViewApps.xml
| | | |
| | | \---templates
| | | \---default
| | | \---application
| | | IncludeApps.isml
| | | SiteNavigationBar.isml
| | |
| | \---share
| | \---system
| | \---config
| | \---cartridges
| | cpt_example_demo.properties
| |
| \---gradle
| \---wrapper
| gradle-wrapper.jar
| gradle-wrapper.properties
|
+---distributions
| |
| \---corporate-distribution-packager
| |
| \---trunk
| | build.gradle
| | gradle.properties
| | gradlew
| | gradlew.bat
| |
| +---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| |
| \---src
| \---init.d
| intershop-init.gradle
|
+---deployment-configurations
| |
| +---deployment_demoserver
| | |
| | \---trunk
| | | gradlew
| | | gradlew.bat
| | | settings.gradle
| | |
| | \---gradle
| | \---wrapper
| | gradle-wrapper.jar
| | gradle-wrapper.properties
| |
| \---deployment_intershopdemo
| |
| \---trunk
| | gradlew
| | gradlew.bat
| | settings.gradle
| |
| \---gradle
| \---wrapper
| gradle-wrapper.jar
| gradle-wrapper.properties
+---custom-fix
| |
| \---trunk
| |
| |
| +---builder
| |
| +---exporter
| |
| +---home-builder
| |
| +---home-expimp
| |
| \---importer
|
+---gradle_user_home
| |
| \---trunk
| gradle_environment.bat
| gradle_environment.sh
|
+---import
| |
| \---trunk
| import.properties
|
\---plugins
|
\---corporate-plugins
|
\---trunk
| build.gradle
| gradle.properties
| gradlew
| gradlew.bat
| settings.gradle
|
+---gradle
| \---wrapper
| gradle-wrapper.jar
| gradle-wrapper.properties
|
\---gradle-corporate-plugin
\---src
+---main
| +---groovy
| | \---com
| | \---intershop
| | \---build
| | | IntershopRepoDefinitions.groovy
| | |
| | \---plugins
| | | IntershopGradlePlugin.groovy
| | | IntershopPlugin.groovy
| | |
| | +---extension
| | | IntershopGradleRepos.groovy
| | | IntershopRepos.groovy
| | |
| | \---util
| | IntershopBuildScript.groovy
| | IntershopPublishing.groovy
| |
| \---resources
| \---META-INF
| \---gradle-plugins
| corporate.properties
|
\---test
+---groovy
\---resources
Note
The example shows the structure in the Subversion repository! On the file system 'trunk' is not available. With GIT the repository structure is different, "assemblies", "componentsets", "distributions" etc. can be different repositories.
Note
Publishing of all artifacts with the delivered script is working only on the original file system structure, but this is independently from the used VCS.
Note
Deployment Configurations
It is necessare to adapt the configurations for the own infrastructure. Paths, user names, ports etc. must be set for the local infrastructure.
Publish All Necessary Artifacts to the Repository
The following artifacts can be published / transferred with the script in the development-setup:
- Project Gradle Plugin
- Project Gradle Distribution
- Intershop Components
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat runBase |
| Command (Linux) | ../gradlew runBase |
Output example:
After the script is finished you can browse the artifacts in the repository.
Distribution
Plugins
Intershop Components
Discussion
This solution prepares all artifacts in the shortest way, but i t is possible to execute tasks for special artifacts separately. The following topics discuss this artifacts more detailed.
There is a short Readme file with basic information in the development-setup folder.
Note
T he following three recipes explain the tasks done in Recipe: Set Up a Project Environment in the Artifact Repository as individual steps.
If the recipe above was already performed, performing the following recipes to create the same environment twice leads to errors.
Note
The deployment policy of some repositories are set to Disable Redeploy, so that it is not allowed to deploy the same module with the same version again. If a process tries to deploy a module with the same version again the artifact repository rejects the request with an HTTP error Bad request 400. These are the possible solutions:
- Remove to module from the artifact repository.
Make sure, that the module is not used by other processes. - Change the version number of the module.
The new module will be used with the next request by other processes. - Change the deployment policy to Allow Redeploy for a special deployment process.
Make sure, that this is changed back after the update process is finished.
Recipe: Create the Project Gradle Plugin
Problem
Repositories should be always configured for all parts in the project in the same manner. Development, test and production should be able to use the same repository configurations in the company or in a special project. This can be done by local init scripts or by special plugins in combination with a project Gradle distribution.
Furthermore it is necessary to control the access to different public repositories. There are different reasons:
- Control usage of licences
- Check security issues
- Network traffic
- Availability
- etc.
It is possible to check the base URL and not to allow access to URLs outside of your network.
It is possible to implement a Gradle plugin for these different requirements. Intershop provides a template for this kind of plugin.
How can a build engineer create the necessary Gradle components to set up a project specific build environment from the template?
Solution
The prerequisites are the same like in topic Recipe: Set up a Project Environment in the Artifact Repository. Also it is necessary to adapt the configuration.gradle in development-setup.
Create the Sources for the Project Gradle Plugin
Execute the following command to create the template for the project plugin
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat createCorporatePlugin |
| Command (Linux) | ../gradlew createCorporatePlugin |
Publish the Project Gradle Plugin
Run the build of the Project Gradle Plugin:
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat publishCorporatePlugin |
| Command (Linux) | ../gradlew publishCorporatePlugin |
The sources of the Project Gradle Plugin are located in a standard Gradle multi project. It is also possible to run the build in multi project directory.
| Working directory | Intershop-<version>/development-setup/ishCDTools/plugins/corporate-plugins |
| Command (Windows) | gradlew.bat publish |
| Command (Linux) | ./gradlew publish |
If all scripts finished successfully, the artifact is stored in the repository.
Discussion
It is possible to extend the project Gradle plugin - add or change patterns or add repositories. This kind of plugin is necessary for all processes in the continuous delivery life cycle. This plugin is also used during the installation in the test or production environment.
Recipe: Create a Project Gradle Distribution
Problem
The project Gradle plugin from recipeabove and other configurations has to be loaded by Gradle before other plugins or configurations are loaded. This is necessary for the preparation of repository configurations and for the usage of special version settings. This can be done by an init script which must be located in a special folder of the Gradle distribution. Intershop provides an template for this kind of artifact, it is necessary to have access to the internet, because the base distribution has to be downloaded from http://services.gradle.org/distributions/gradle-1.8-bin.zip.
See Chapter 60. Initialization Scripts in the Gradle documentation or Screencast: STANDARDIZING AND ADMINISTERING YOUR ENTERPRISE BUILD ENVIRONMENT .
How can a build engineer or specialized developer create the necessary custom distribution from the template?
Solution
The prerequisites are the same like in topic Recipe: Set Up a Project Environment in the Artifact Repository. Also it is necessary to adapt the configuration.gradle in development-setup.
Create the sources for custom distribution
Execute the following command to create the template for the project gradle plugin.
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat createCustomDistribution |
| Command (Linux) | ../gradlew createCustomDistribution |
Publish the custom distribution
Run the build of the custom distribution.
| Working directory | Intershop-<version>/development-setup |
| Command (Windows) | ..\gradlew.bat publishCustomDistribution |
| Command (Linux) | ../gradlew publishCustomDistribution |
The sources of the project Gradle plugin are located in a standard Gradle single project. It is also possible to run the build in project directory.
| Working directory | Intershop-<version>/development-setup/ishCDTools/distributions/corporate-distribution-packager |
| Command (Windows) | gradlew.bat publish |
| Command (Linux) | ./gradlew publish |
If all scripts finished successfully, the artifact is stored in the repository.
Discussion
In special cases it is necessary to adapt the init script of the custom distribution, e.g., add plugins to all projects.
Recipe: Import the Delivered Intershop Components into the Artifact Repository
Problem
All components of an Intershop delivery are delivered in one large Zip file. This file contains all necessary components for build, installation and runtime. These artifacts are not usable in a shared environment. Therefore, it is necessary to transfer all necessary artifacts to a remote repository. Intershop provides a plugin and a script for this task.
How can a build engineer or specialized developer transfer the artifacts to a remote repository?
Solution
It is necessary to unzip the package and adapt a configuration file (see Recipe: Set Up a Project Environment in the Artifact Repository ). It is also possible to use the prepared import file from the development-setup.
An exception occurs if ucp and ojdbc are not copied into oracle-jars. Is this necessary, when you just want to update your repo?
At least this must be stated here as a prerequisite.
Adapt the Configuration File
The import.properties file is located in the directory Intershop-<version>/import.
# import properties for the Intershop artifacts # Which repository will be used? # remote - All artifacts will be transfered to a remote repostiors # like Sonatype Nexus or JFrog Artifactore or others. # This is the most recommended setting for a standard setup. # local - All artifacts will be transfered to an other local repository. repo = remote # These are the settings for the remote repository. # # URL of the repository for Intershop releases # example: # target.repo.url = http://hostname:port/nexus/content/repositories/releases target.repo.url = http://hostname:port/nexus/content/repositories/releases # These are the user settings of an user with the permission to # upload artifacts to the remote repository. # example # deploy.user.login = admin # deploy.user.password = admin123 deploy.user.login = admin deploy.user.password = admin123 # This is the path for a other local repository. target.repo.dir = /local/repository
Run the Import
| Working directory | Intershop-<version>/import |
| Command (Windows) | ..\gradlew.bat publish |
| Command (Linux) | ../gradlew publish |
If all scripts finished successfully, the artifacts are stored in the repository. It is also possible to check the available version for artifacts.
Discussion
Intershop provides a plugin for this export and import task. Thus, it is possible to export a special version in the remote repository to a local repository. This can be helpful for a local installation outside the network with the artifact repository.
Summary
When all these steps are finished successfully,
- all necessary artifacts are stored in the artifact repository and
- the base system component set, assembly, the developer configuration and deployment configuration for demo systems are stored in the VCS
the developers of a project can start with their work.
The setup of the CI server is not part of this document, but the CI server is working like a developer. This server executes the same commands on the working copies, so the project Gradle plugin, the distribution, the system component set or the assembly can be started like the solution of Create a Project Gradle Plugin.