Go beyond Java with CI server and Artifactory
1. Developers fetch needed dependencies (3rd party libraries, other modules). 2. Developers write new code. 3. Code is committed to VCS. 4. Build server polls VCS for changes. 5. Once discovered, the build server builds the software: compiles it, runs tests, and assembles artifacts. 6. Built artifacts are published to QA, staging, or even directly to the end users. As you can see, everything except stages 1 and 6 is well known and familiar. But what about those two stages? You need a dependency management mechanism for them. In this post, we’ll illustrate the options for automated builds with dependency management in non-Java builds or when not using .NET with NuGet (use it, if you can! Here’s our take about it). The proposed solution works for any kind of build, be it C, C++, C#, iOS and Objective C, Python, or whatever. So, let’s see how you can implement CI with dependency management for non-Java projects. Here are the options with their pros and cons:
#
|
Solution
|
Pros
|
Cons
|
1
|
Dependencies in VCS
|
– Use proven build tools
– Simple setup – you use VCS anyhow
|
– VCS won’t fit for binary dependencies. You can read whyhere.
|
2
|
– Build tool with dependency management
|
– New tool to learn. Both Maven 2 and Gradle have a pretty steep learning curve.
|
|
3
|
Declare dependencies on builds in your build server
|
– Use proven build tools
|
– Only works for inter-project dependencies (which were built by the same build server)
– Not flexible enough – Includes/excludes – Layout changes
|
4
|
Use shared dependencies storage, a.k.a. “repository” (FTP, file server, etc.)
|
– Use proven build tools
|
– Manual repository populating
– Managing the repository
|
As you can see, none of the solutions are without the cons.
Here comes Artifactory
Next, configure your custom deployment and resolution rules. Let’s start with deployment (publishing):
In the above example, we configured the following rules for deployment. All the artifacts will be deployed from the working directory into the ‘libs-release-local’ repository (configured above),maintaining the path for each file:
Pattern
|
Meaning
|
**/x64/*.dll=>x64Win
|
Deploys all DLLs to the ‘x64Win’ directory
|
**/*.zip=>winFiles
|
Deploys all zip files to the winFiles directory
|
unix/*.tgz
|
Deploys all tgz files under the unix directory to the root directory of the target repository
|
In the above example, we configured the following rules for dependencies resolution:
Pattern
|
Meaning
|
libs-release-local:x64Wi/*; compatibilityLevel =medium,high
|
Resolves the files from the x64Wi directory of the libs-release-local repository to the root of the workspace, but only if the ‘compatibilityLevel‘ property is set to be above medium
|
libs-snapshot-local:*.zip=>winFiles
|
Resolves all zip files from libs-snapshot-local repository to winFiles directory under the root of the workspace
|
libs-snapshot-local:unix/distro.tgz=>linuxFiles
|
Resolves the distro.tgz file from unix directory in libs-snapshot-local to linuxFiles directory under the root of the workspace
|
libs-release-local:**/* @winx64_build#released
|
This example shows dependency to artifacts produced during an earlier build that has been marked with a “released” status
|