JFrog Integrates with Perforce for a Smooth Release!

May 18, 2012

Back at JavaOne 2010, JFrog announced that its Artifactory repository manager solution will be an open tool, supporting all the build technologies (e.g Maven, Gradle, Ivy, etc.), integrating with the developer ecosystem, and providing one with the freedom to choose the right tool stack without vendor lock-in. Following the open source plugins for tools like Jenkins, TeamCity, Bamboo, NuGet, Subversion and others, JFrog now adds Perforce integration to its Release Management feature in Artifactory. This feature is a part of a broader Build Integration support and it is critical for automation of a company’s deployment procedures. In this post, I’ll explain what you can achieve with this feature and how to use it.

What is Release Management?

Release management is a part of application lifecycle. Assuming that your product is continuously built and tested, at some point you decide that it is ready for release. Next stage - releasing it. It is not just about changing the version from integration to release one , although it also should be done. The release process usually includes staging (“release candidate”), labeling the corresponding source code in your VCS, changing the access level to your artifacts (usually, QA or beta-testers will be able to access the release candidate and a broader audience will access the release version), and any other operation your business logic dictates.

Once you use the correct toolset for the job (such as a Version Control System like Perforce; a build server like Jenkins, TeamCity or Bamboo; and Artifactory as binary repository), you’re good to go.

How does it work?

This is what daily work (building of nightly/integration/snapshot versions) looks like:

nightly integration snapshot

  1. Developers write new code.
  2. It is committed to Perforce.
  3. Build server polls Perforce for changes.
  4. Once discovered, the build server builds the software: compiles it, runs tests, and assembles artifacts.
  5. At the end of the build, those artifacts are deployed to Artifactory.

This cycle goes on and on until you decide you’re good to stage a release candidate. Once you click the “Build and Release To Artifactory” button, the Artifactory release plugin kicks in.

Here’s what happens. The screenshots below are from Jenkins, but the concept is similar for Bamboo and TeamCity:

artifactory release staging

  1. The version of the module in the project descriptor/build script (be it Maven’s pom.xml or Gradle’s build script) is changed from integration to release. The plugin provides reasonable defaults for what the next release version should look like, e.g. 5.1.1 for 5.1.1-SNAPSHOT, but you, of course, have the last word and can set it to whatever you like, including writing your own version transformation in Groovy (starting from Artifactory 2.6).
  2. Now, when the sources are ready, the release candidate is built.

  3. Upon a successful build, a Perforce label for the new version is created. This label will be used for maintenance of the released version.

    perforce label

  4. The changed build descriptors/scripts are committed to the new label.

    build descriptors scripts

  5. The version of the module in project descriptor/build script is changed again, this time to the next integration version. The plugin, again, will try to guess, but you have the last word.

  6. The changed build descriptors/scripts are committed to the trunk for further feature development.

  7. The newly built Release Candidate is deployed to a dedicated target repository (selected by you, of course) in Artifactory. Whoever has the access to that repository will be able to see and try out the new Release Candidate. During the deployment the artifacts are tagged with the relevant searchable properties. Now they can be found with ease, as  seen below:

     

    repository search snapshot

In case of a failure during that process, the plugin will do its best to cleanly rollback any changes (local and committed). For example, the label will be deleted and the changed integration build scripts won’t be committed.

Now, when your Release candidate is ready, go test the hell out of it. When you reach the conclusion whether this build is good to become a release or not, you just promote it to be a release (the plugin will move/copy the artifacts to public “release” repository) or roll it back (in that case, it is moved again to a special repository). You can also apply your own Groovy-based promotion logic (starting from Artifactory 2.6).

artifactory release promotion

You can watch the whole process in the following screencast.

As I am sure, you know that a robust, automated and agile release cycle is a critical piece in the continuous release process. Now it is easy to do with Perforce, a build server and Artifactory.

Enjoy your build!

The Artifactory Team

rdefauw's picture
About the author

Randy DeFauw was a Technical Marketing Manager at Perforce Software. Prior to joining Perforce, he was a certified Perforce consulting partner and trainer. He has extensive experience with Perforce configuration, administration, and integrations.

See all posts by