JFrog jumps at Devops opportunity with continuous integration repository

Analyst: Jay Lyman 

Israel-based JFrog backs the open source Artifactory repository management software, where it finds audience with both application developers and IT operations teams.

Its positioning between these two parties managing one of their common challenges in software artifacts and binaries places JFrog at the crux of the devops trend that is pulling development and IT operations together. While its Artifactory software and repository management remain somewhat unique in the industry, we see a growing list of competing vendors and categories, particularly as more development and operations center on cloud computing.

The 451 Take

JFrog and its repository management software benefit from their unique position at the crossroads of software developers and IT operations, or dev! ops, where the two come together primarily for speed and efficiency. JFrog's early all-in bet on the Jenkins continuous integration server, a fork of the Oracle-owned Hudson, appears to be paying off as the market continues to favor Jenkins. Looking ahead, it will be critical for JFrog to differentiate itself as other vendors and categories cross more over into competition. Also key will be JFrog's ability to integrate and grow with PaaS offerings in the market, but we expect we will see the company consistently here.

Context

JFrog, based in Netanya, Israel, backs the Artifactory binary repository management software, which is open source under the LGPLv3 license. The company was founded in 2008 by its current CEO Shlomi Ben Haim, its current CTO Yoav Landman and current Chief Architect Frederic Simon, all of whom haved worked in the Java and open source communities together. JFrog has about 16 employees, most of whom are engineers, and plans to have a h! eadcount of about 40 by the end of 2012. The company launched ! its first paid product Artifactory Pro at the end of 2009, starting with some key, large customers including LinkedIn and Netflix. Today, JFrog reports almost 250 paying customers and its binary repository management software running on the same number of servers. JFrog says it is currently considering venture capital investment options, but is well funded from its own income and angel investment from its launch.

Products

JFrog's Artifactory product manages binary repositories as software moves through development to testing and quality-assurance and eventually to deployment. The software sits as a proxy between other development tools used in managing software repositories and continous integration, such as Apache Ant and Maven build automation, Ivy dependency manager and Gradle project automation. Artifactory caches software artifacts so repeated downloading is not necessary. Artifactory also blocks unwanted or external requests for internal repository artif! acts, controlling how, where and by whom artifacts are deployed. This helps to manage artifacts and third-party dependencies used by developes and IT operations, which can also share repositories among different departments or teams using Artifactory. The Artifactory software itself is built on the Java Content Repository, which helps support high concurrency and data integrity, the company says. Artifactory's underlying storage, which is backup ready, also supports the attachment of searchable XML metadata and user-defined properties via JFrog's OpenMetadata technology. The software features granular permission controls that can be managed through a simple UI.

JFrog offers its Artifactory repository management software in two versions, Pro and Cloud. Artifactory Pro is an annual subscription that includes a set of paid add-ons bundled with the open source software. The Pro version, priced at $2,350 per year, includes updates, full maintenance and bug fixes as well as a growing list of add-ons for continuous integration server support, resource management, license control, search and other capabilities that go along with the repository management. The cloud version, Artifactory Online, is the same offering in SaaS form with SLA support. Users can quickly set up private repositories using the service without the typical requirements of configuring and customizing a server and access.

The newest version of the software, Artifactory 2.6, is expected in the second quarter of 2012 and is focused on customizable release management. Much of this centers on extending Artifactory management beyond pre-staging to encompass more of the software release process. The idea is to speed the time between software testing and release by maintaining consistency and manageability of software repositories.

Technology

JFrog reports that the use and proliferation of cloud computing has resulted in an enterprise software release process that requires the management of software binaries and repositories much earlier in the effort. This coincides with the trend of devops, which demands that developers and IT operations work closer together and consider each others' roles and responsibilities more thoughtfully. JFrog says that while binaries are closely tracked through testing and QA phases, they can quickly get lost once code hits production. Thus, Artifactory i! s aimed at supporting that move of software to production. JFrog says it is gaining traction with Artifactory Online because of a move by major players, including SpringSource, to put more of their development and support in the cloud.

Artifactory also integrates with a key devops technology: continous integration servers, including Bamboo , TeamCity and Jenkins. JFrog is also benefiting from its decision to support Jenkins, which is a fork of the Hudson continuous integration server from Oracle. While we saw the market supporting both servers last year, it appears there is more momentum and vitality for Jenkins currently and this appears to be contributing to traction for JFrog.

Another part of JFrog's current growth centers on its focus on application programming interfaces (APIs), which have emerged as critical for promoting communities around connectors and plug-ins. JFrog stresses the importance of giving its users and customers a stable, documented API along with examples. JFrog also highlights that APIs are a sort of common language between software developers and IT operations teams, which both work closely with APIs to make things work.

Finally, JFrog is also adding more support for .Net and the Windows world, particularly with its recently-added support for NuGet, a .Net package manager. Through an add-on, Artifactory can support and proxy NuGet packages for Visual Studio .Net applications. This is significant as we see .Net and Windows catching up in devops after trailing to mostly Linux and open source programming frameworks and languages the previous few years.

Integrations and partnership

Artifactory is commonly deployed alongside other key devops technologies, including the continuous integration servers such as Bamboo and Jenkins as well as server automation frameworks such as Chef and Puppet. The Artifactory software also works with a range of other development tools in dependency management, build and project automation and other areas. JFrog also partners with CloudBees, a PaaS provider that is centered on the Jenkins CI server.

Competition

Its work in Java and Apach! e means that JFrog is competing mostly with Sonatype, backer of the Apache Maven and its own Nexus repository management software. While JFrog supported the Jenkins fork of the Hudson CI server last year, Sonatype remained supportive of Hudson. This continues to be the case today and while the market does seem to be favoring Jenkins, the fact that Oracle still backs Hudson may intensify the competition from Sonatype. Another category of competitors comes from the code vetting and management world, where vendors such as Black Duck continue to extend further into the development process. Other competitors here include OpenLogic, Palamida and Protecode. Another area that may represent more competition for JFrog going forward is cloud monitoring and management. For example, Electric Cloud is a cloud automation and devops vendor that includes artifact management in its offerings. JFrog must also compete with use of other open source software for repository management, such as th! e Apache Archiva repository manager.

SWOT Analysis

Strengths

JFrog and its Artifactory repository management software sit at the crux of the growing devops trend in its technology and support for both software developers and IT operations.

Weaknesses

The company remains somewhat obscure and is lesser known than other vendors in the small but growing devops space.

Opportunities

The growth of devops practices and processes among both newer, Web 2.0 type users and more mainstream enterprises could provide more than enough fuel for JFrog's growth.

Threats

Other vendors, particularly those dealing with software development and deployment in the cloud, are increasingly offering similar repository managemenet features and capabilities.

QCon 2012 - Perfect as Everything in London Should Be

It was JFrog's second QCon London, and it just gets better. Imagine: even the London weather was perfect, not to mention the sessions, booth traffic, show organization and food (what, you say, good English food? Well, great IndoPak food, at least). Due to high demand by sponsors, the exhibition took place on two floors (as opposed to one floor last year). Our JFrog booth was located in the same place as in 2011. We’re getting used to the place and are looking forward to returning next March!

The speaker panel was extremely impressive, featuring gurus like Martin Fowler, Adrian Cockcroft (the man behind Netflix’ cloud), Dwight Merriman (co-creator of MongoDB), Damien Katz (creator of CouchDB) and Rich Hickey (creator of Clojure).

The conference started with two training days - six full-day tutorials each. From my perspective, the most interesting two tutorials were “Cloud Architecture” by Adrian Cockcroft, where he shared the architecture, best practices and decisions behind Netflix’ cloud (which Artifactory is proud to be a part of) and “Continuous Delivery” by ThoughtWorks’ Tom Sulston (that’s as close to the roots of the famous “Continuous Delivery” book as you can get). For me, the most fascinating thing in the Continuous Delivery process as ThoughtWorks sees it, is that its virtues are exactly the same as we based our Artifactory upon back in 2006: DevOps automation and rapid release cycle. We appreciated the validation of our concept.

The remaining three days of the week were all-day sessions. It’s impossible to review such a significant number of talks in one blog post, so I’ll concentrate only on the excellent keynote addresses (with one exception).

Martin’s conference-opening keynote speech was about data. The main feature of modern data is that it is bigger than you think. Polyglot storage in general and various kinds of NoSQL look like the right solution.

My favorite keynotes are usually the evening ones. A beer in your hand makes any amusing talk even more enjoyable. One named “Developers Have a Mental Disorder” I couldn’t miss! Greg Young gave a great show, funny and entertaining, about serious dilemmas in software development that we, the developers, prefer to ignore. The brightest example, of course is the downside of DRY (did you ever think about one?). By removing duplication, we increase coupling, which can be much worse.

Thursday morning’s keynote address was delivered by Rich Hickey. He spoke about the differences between “Simple” and “Easy”. Sounds pretty similar, but in fact they are very far from being the same. Antonyms to the rescue: simple vs. complex, while easy vs. hard. Now it’s clear - we need to strive to prevent and remove complexity (go simple) without being afraid of the hard. Choosing easiness may end up creating complexity. Things which are easy, but complex, include OOP, mutable state, imperative loops and frameworks (especially ORM). Things which are simple, but not necessarily easy (at least not until you get them), are LISP-ish languages, like Clojure.

My session also took place on Thursday, in relatively small room, about 70 people. I was more than happy to see that it was almost packed. I spoke about building trust in your build process by selecting the right tools for the job (of course, we consider Artifactory as one). I also spoke about the problems of DevOps in the word of Continuous Delivery in the cloud and the rapid release cycle of SaaS applications. I stressed the huge timeshare of binaries in ALM process and the importance of using a tool that really understands binaries to deal with them. That’s exactly the reason why we developed Artifactory.

Half of my session was dedicated to live demos, which went smoothly, incredible as it may sound. According to the feedback received, my talk was well accepted, and hopefully will be useful to some of the attendants for building easier and more reliable release processes. The Q&A session continued at our booth, where we repeatedly did live demonstrations and received excellent feedback each time. If you want to get a feeling of my talk, here’s the slide-deck.

Friday was the last day of the conference. It started hard with a highly technical keynote address by John Allspaw with a scary name: “Resilient Response In Complex Systems”. For someone like me, who doesn’t deal on a daily basis with Disaster Recovery, the session was astonishing. Looking behind the curtain of that kitchen reveals a totally different way of thinking and planning. It may be how individuals and teams have to perform during a disaster (e.g. personal heroism is bad even if successful; it sends the wrong message to the team), or simulating disasters on live production systems (I never could even dare to think about that). The most obvious, but still eye-opening advice that John gave is to learn from successes, not only from failures. It can give us a lot of information and happens much more frequently, no? The only organization with which I am familiar that embraces that technique is the Israeli Air Force.

To sum up, the conference was great by every measure: technical sessions, attendance, networking, Artifactory exposure, and after-show quality time. Thank you, InfoQ, for this wonderful event in London. QCon was a great starting shot for JFrog’s “Busy March”. You still can catch Fredric and Yoav giving talks on various events in US and Europe.

Dependency Management with .NET - Doing it Right

The problem of dependency management is neither new nor original, it exists in all development platforms, and .NET is no different.
Let’s go through different solutions and see how they perform. I’ll list them here in no particular order.

Keeping dependencies in your source control
That’s a very popular solution, and for a reason. The benefits are obvious. Here are some of them:

• No setup. You already have your source control in place (hm, I hope you do!). Add \bin directory, and you are fine.
• No learning curve. Developers are used to work with source control.
• Shared. The whole team gets changes and updates from the server as they occur.
• Enterprisy (in a good way). The software is proven, backed up, DRP is done.

Sounds good, doesn’t it? So, what’s wrong with it? Only one thing - source control systems are designed to control, well, sources. As such they aren’t so great in controlling binaries. These are the shortcomings we all encountered during the years of Version Control System usage for dependencies:

• It isn’t a proxy. VCS can’t download the dependency you need from a central repository when you need one. You need to manually download it and add it to VCS. The history starts from there - you just lost the  link to the original file. So, you work hard, and on top of it lost information; this repeat itself for each new dependency.
• Versioning mismatch. Source files are versioned by their content. VCSs know how to diff them and understand what changed. Binaries, on the other side, usually versioned by their name. From VCS point of view they are different entries, each one without any version history.
• Some very popular VCSs (like Subversion) can’t obliterate files. That means - once a file was added, it stay in the repository forever. That’s not a big issue for small source files, but can become quite a pain when it comes to obsolete large binaries.
• Source control knows how to search sources. And, of course, the most important type of search is by content. Searching for binaries is different: what matters there is the location, structure of the file name and, in case of archived artifact, the contents of archive.
• The permissions scheme of VCSs is tailored for versioning sources (again!). For example, there is no override permission. That’s because overriding sources is something we do all the time (that’s what diff is for in VCS) - it’s the same security level as, let's say, adding a new source file. With binaries the situation is very different. While adding new binaries is fine, overriding released binary is something that shouldn’t be done, one should have a special permission for it.
• Distributed VCSs, awesome by themselves, are particularly unsuited for handling big binary files. When cloning a remote repository to your machine you are bringing all the history of all the files in it. Now just think about all the huge binaries sitting there...

As you see, the conclusion is simple - we can do better. Let’s try something specialized for binaries.

GAC and WebGAC
Global Assembly Cache is, on contradictory to VCS ,tailored for storing binaries. It understands versions, prevents conflicts, and generally does a good job being your local dependencies storage. The main problem with GAC is being local, which means - each and every developer should take the binaries from somewhere and install them in their local GAC. You see the troubles coming in that setup, don’t you? WebGAC to the rescue here. It's essentially GAC shared by WebDAV and enables clients to fetch dependencies from the server, simplifying dependencies management for a team. Let’s do our pros/cons math. The benefits:

• GAC is good, standard and proven solution for binaries management. It deals well with versions.
• WebGAC is a central binaries repository for a team. Every team member synchronizes with it.
• WebDAV is popular well-known HTTP extension with locking, security management, etc. Working with the Apache WebDAV module is generally straightforward.

Let’s see what won’t work so great with that solution:

• It isn’t a proxy. WebGAC can’t download the dependency you need from a central repository when you need one. You need to manually download it, add it to WebGAC and only then it becomes available to the team. Not only must you work for every version of every dependency needed, the link to the original file is lost.
• No notion of packages. GAC contains single dlls. You install them one by one. But think about NUnit, as an example. It contains about dozen of dlls along with various xml and configuration files. How can you install it to GAC?
• Security is cumbersome. You’ll need to configure Apache Server’s security, and even then it won’t be flexible enough to determine between deployer (a user that can publish private dependencies) and promoter (a user that can move dependencies from a private repository to a public one).
• Search is basic. WebDAV by itself only knows about files. It doesn’t care about the structure of the filename, or about the presence of Strong Names.

Looks like we still didn’t find what we are looking for, and then...

Here comes NuGet
This is something else. NuGet designed to be “a developer focused package management system for the .NET platform intent on simplifying the process of incorporating third-party libraries into a .NET application during development”. That’s exactly what we need. Let’s look how great it is:

• Manages packages, not dlls.
• Provides NuGet Gallery - almost 4.5K (at the time of writing) packages are at your disposal for all your development needs.
• Supports binary versioning.
• Integrates with Visual Studio.
• Integrates with your build.
• Integrates with your build server (only TeamCity at the moment of writing).

This tool's like a dream come true. So, what can I mention as downsides? Most of them are downsides of the NuGet Gallery, not NuGet itself. The Gallery is a young and relatively small project (just for the sake of comparison, Maven Central is 6 years old and contains more than 290K artifacts) and, as such, it has its downsides:

• The content of submissions to the Gallery is (almost) unverified. Everyone can register, get the API key and start uploading whatever they like. Scary, isn't it? (yes, very scary).
• Being public, NuGet Gallery can’t be used for inter-team packages exchange. Private Remote Feeds are the recommended solution. Next we'll see if it is good enough. 

 Working with NuGet Remote Feeds
Remote Feeds, introduced in NuGet 1.4 are crucial need for any development team. It serves a dual purpose: it allows sharing 3rd party packages that aren’t available on Gallery (or even replaces the Gallery for those who can’t trust it) and it serves as a target for internal deployments - both for team collaboration and for other usages, as making packages available to QA, or even serving them to the customers from the outside world (by using Chocolatey, for example). If that’s so right, what’s wrong? Here’s what:

• You saw it coming: It isn’t a proxy. You know the score by now.
• It can’t aggregate. The NuGet Remote Feed exposing one monolithic repository: the one you have on your machine. It can’t aggregate NuGet packages from remote repositories, or expose number of local repositories (separated for security reasons, for example).
• You can’t attach your own metadata. Let’s say you want to annotate some package with compatibility information (e.g. works with certain browsers). No, can’t do.
• The repository is very simplistic. It doesn’t provide any web interface; it browsable and searchable only from a client - be it Visual Studio or the command line interface (pretty basic by itself).
• Even the VS search interface is very basic (all you have is arbitrary sorting and free text search). It should be enough for starters but lack of searching inside the packages or by properties (from the previous bullet) will bite you eventually.
• The security scheme is even less than simplistic. All that's required to authenticate a deployment/delete of all the users at once is an API key. What about separation of duties? Some users should only be able to read, others only to annotate with metadata (QA team that tests compatibility in my previous example), and only small subgroup - to deploy.  The all-or-nothing scheme is definitely insufficient.
• Storage format is suboptimal:
  • The packages are stored on the filesystem in a naive simple format. That fine for small repository,but as you grow, you'd expect storage which more optimized for binaries.
  • The metadata is not indexed. Again, fine for small repo, troubles are foreseen when it comes to scaling.

So, is there a good alternative to NuGet Remote Feed to be your in-house Gallery for NuGet packages? We, the proud makers of Artifactory,  believe there is:

Meet Artifactory
Artifactory is an enterprise-grade Binary Repository that centralizes all aspects of managing software binaries. That means that we tackle all the problems mentioned above. We are developing Artifactory since 2006. Being used by millions of users for storing, sharing and managing binaries, we have gathered great feedback from our users.
That's what we've learned:

• Binary packages are different from sources (by being big and binary) and deserve smart storage.
• Binary packages are usually archives (be it jars, zips, rpms or nupkgs). They should be browsable and searchable without the need to download them locally to developer's machine.
• Big public repositories exist on the net, they need to be proxied smartly (variations, auditing, managing)
• Users come in different flavors. Their permissions should match possible responsibilities (and in the case of binary packages they are different from other cases).
• A binary repository holds critical information, it should be rock-solid, backed up, and DRP ready.
• Your software ends up being a package. We know how to help you...
  • build it in a reproducible manner, integrating with your build tools and your build server.
  • stage it to ensure the best quality.
  • distribute it to your customers.

You get the gist behind Artifactory by watching this 2.5 minutes YouTube video. If you’re not in the mood for movies (or ran out of popcorn), here’s quick recap (click on the image for full size):

As you see, instead of working with a number of NuGet Feeds (NuGet Gallery, Orchard Gallery,  Remote Feeds from co-workers and from different teams) developers work with exactly one repository. It simplifies setup and daily work and centralizes management and maintenance.
The work is bi-directional, the users resolve their 3rd party dependencies from Artifactory and deploy their created packaged into it.
Now let’s add a build server to the picture (literally):

Yup, with numbers this time. So, here we go (click on the image for full size):

1. Developers find and  fetch new 3rd party packages from Artifactory in Visual Studio. The packages are downloaded from Artifactory to the developer's machine. If the packages aren’t present in Artifactory it will look for them in remote galleries/feeds. On developer machines packages.config is updated with the list of used packages.
2. Developers commit their code and packages.config (but not the binaries) to VCS.
3. The Build server (as I already mentioned, TeamCity now supports NuGet) takes the changes from the VCS.
4. It builds the solution and packs the produced artifacts as NuGet packages.
5. During the build it fetches the needed packages from Artifactory. If the packages aren’t present in Artifactory it will look for them in remote galleries/feeds.
6. Once the packages are built they are deployed to Artifactory.

Built packages in Artifactory can be used by other teams (as their 3rd party dependencies), by QA for running tests and even by the end users (Chocolatey FTW), all this with fine-grained permissions and robust promotion procedures (moving a package between repositories with different visibility rules).
You know what? It deserves dedicated how-to blog post. I’ll link it here once published.
Assuming you've read up to this point, you've gathered that starting from Artifactory version 2.5.0 we are proud to serve the .NET world with full NuGet support. We can proxy any remote NuGet feed (starting with NuGet Gallery, of course), we can host the packages that aren’t found on any remote NuGet feed, we can host the packages you produce and we can aggregate any number of repositories of any kind under single a URL. We provide you with an awesome UI for configuring your repositories, browsing and searching for your packages. We also feature smart storage that enables attaching searchable metadata on top of your binaries. We can do it all on the cloud with our SAAS version.
Hopefully , you're convinced by now and probably looking for the download link on our site (here’s it, BTW, click on “Evalution”). If not, give it a try by playing with our live demo. Look at the nuget-gallery cache: that’s how we proxy the NuGet Gallery. You’ll find some of the packages saved locally; once you've selected a package, you’ll see all kinds of information about it: its name and size, who deployed it to Artifactory, where it came from (from NuGet Gallery, naturally for this is the NuGet Gallery cache) and the operations you can perform on this package (as anonymous the selection is naturally limited). Clicking on the triangle in the tree will open the package and let you dive into its content, including downloading specific files from the archive:

We, at JFrog, believe that Artifactory is the missing piece of the puzzle for a robust, agile .NET dependency management, which can make the development process easier compared to other alternatives.
We'll be happy to receive any insights, thoughts and comments on the ideas presented in this blog and/or your experience using Artifactory together with NuGet.

Artifactory - Community Talks

We’d rather have our customers and users be the gauge of how well Artifactory met their Continuous Integration needs, rather than have you listen to our opinion.

These are busy days for the froggers getting ready to release 2.4.
The buzz is out there and proudly we can see more and more talks that cover Artifactory as part of their CI case-studies.

Following the DUKE CHOICE AWARDS in which Oracle honored us at JavaOne 2011 with the DUKE for "Innovative Tools for Developers", we would like to share with you these two great video presentations:

Building for the Cloud - Carl Quinn of Neflix talks at JavaZone and covers Netflix pipeline using Jenkins and Artifactory.


Building for the Cloud from JavaZone on Vimeo.

Agile Application Lifecycle Management - Author of Agile ALM, Michael Hüttermann, JavaOne talk. Michael describes how to execute an agile release management process using Jenkins, Artifactory and Maven.



Enjoy Artifactory!

The Frog Who Turned into a Prince

JFrog’s Artifactory Wins JavaOne 2011 Duke's Choice Award

3 years from the day it was founded, JFrog was recognized by Oracle and the Java community  for Innovation Java Tools for Developer with Duke’s Choice Award at JavaOne 2011.

This is not a marketing announcement nor a techie or an executive post, this blog is about how we felt the morning after we became Dukers’.

It’s been more than a year since I posted “That's what community for”, I was sure that I felt the power of the open source community, and than came DUKE...

It was Saturday around 2:00am, few weeks before JavaOne that I got the mail from Michelle Kovac of Oracle with the fantastic words “you're in the winners list right now for JFrog”. It took me 3 times to read the mail, and to actually hold the DUKE a few weeks later - to believe it!

On Sunday evening, Oct. 2nd, at the JavaOne Open House, Oracle welcomed and celebrated the 2011 Duke's Choice Award winners, JFrog Artifactory was one of them. Together with 9 other innovative Java projects, we "the froggers” stood there and felt like we got kissed and turned into a prince.

Now, you might say - OK this guy took it a bit too far...
So Imagine that you have been working like crazy for the last years (6 years since Yoav Landman, our CTO, first launched Artifactory and 3 years since we founded JFrog), your team beating any time-zone gap, and writing excellent code. You know that you are a game changer in the way people write code and you actually solve the developers pain, but still hear questions like: “So what is a Binary Repository Manager ?!” And “what do we need it for, if we use a version control ?!”

Imagine that during the last several years, you write open source based plug-ins to integrate with Artifactory’s ecosystem -  just to keep Artifactory “open” and to keep the freedom of choice in the developer’s hands, and you know that you are fighting giants with that approach.

Imagine that you have been travelling all over the world “preaching” how your Continuous Integration process should look like and how you should build, deploy and distribute your software, and little by little you see followers doing as you advised.

...and then, finally you got this huge hug from the community through Oracle.

I know its better to play the cool CEO, but JFrog is all about soul and I tell you it was (and still is) awesome!!!

Fred Simon our Chief Architect tried to expressed that in the live Java Spotlight podcast - in 2 minutes talk, but we know it took much longer to come up to this point of recognition.

A week after JavaOne, we are back to ground and working hard to release Artifactory 2.4 with lots of improvements and new cool features like P2 integration to proxy and host all your Eclipse plugins via Artifactory and YUM repository for distributing RPMs directly from your Artifactory server acting as a fully-featured YUM repository.

We got the DUKE CHOICE AWARD from Oracle and we are very honored and excited, but I keep remembering the words of one of the JUG’s leaders from the other night at the conference “you’ve got a great tool and a great team - you deserve it” - that’s more than a trophy, this is what we are here for, it’s our reward and we are grateful!

We are very pleased to receive this acknowledgement of our technological achievements by Oracle and the community. JFrog strives to provide our users and customers with advanced technology solutions that address their daily CI needs and driven by it.

I once wrote “community isn't a flock” now I know it for sure!

Thank you , Enjoy your build, Enjoy Artifactory.
See you at JavaOne 2012.

About JFrog:
JFrog is the home of Artifactory – world’s first Binaries Repository Management Solution. As the first company to provide the software market with a Repository Management Solution, JFrog has established itself as a technology leader in the industry and aspires to continue setting the standard moving forward.

About Artifactory:

With Artifactory, you can gain full control over all the build artifacts and third-party dependencies your organization uses and even share repositories throughout your interdepartmental and/or multi-team environment no matter where your team members may be located.

Built on top of the Java Content Repository (JCR), Artifactory supports extremely high concurrency and offers unmatched data integrity.

Artifactory is also tool that offers an open source, Pro and SaaS (cloud based) versions.

More about the DUKE adventure at:

http://blogs.oracle.com/java/entry/and_the_winners_are_the
http://www.youtube.com/watch?v=Lrq4UBGgQpg
http://java.about.com/b/2011/10/06/dukes-choice-award-winners-2011.htm

Jenkins New Maven and Gradle Release Management and Why You Should Look Into It?

Jenkins now offers a new robust solution for release staging and promotion in the form of the Jenkins Artifactory Plugin. This solution is fast, lightweight and works for for BOTH Maven and Gradle builds

The Need for a Better Release Alternative

If you are using Jenkins (or Hudson, before) then releasing and promoting build artifacts isn’t necessarily a flawless experience or may not be completely solved. To go over the main reasons of why this is so, I would like to look at Maven and Gradle builds separately.

Maven and the M2 Release Plugin

First, Maven. Jenkins already has a solution for releasing Maven artifacts in the form of the m2 release plugin. The plugin is essentially a wrapper on the client-side Maven release plugin. When it executes it runs an out-of-process Maven build with release tasks. This is natural for a plugin that was designed to run by a user on his machine, but running it server-side has a couple of serious issues:

• The m2 release plugin invokes its own Maven instance that may be of a different version than the one defined for the job. Jenkins, not controlling this build, will not record any information about the release artifacts and will not archive them
• The plugin also uses different SCM settings and credentials than the ones defined inside Jenkins. This double-configuration is error prone, and makes reproducibility difficult
• Rollbacks are hard. With no built-in automatic rollback, when failure happens in the release flow, rollbacks become a manual task. Without a CLI, and given that the run is not interactive, this becomes even harder. Moreover, SCM tags are created with credentials that users may not have access to
• It is unnecessarily SLOW. In fact, a release flow involves 3(!) full clean/compile/test cycles (you can read more about this in this blog post)

Gradle
If you are using Gradle, you are already driving your builds with elegant Groovy model+script. You may want to take advantage of that and enrich your builds with custom release logic via a Gradle plugin, which may be enough for your needs. However, there are some drawbacks to this approach:

• You will need to duplicate the plugin configuration in each new project and introduce release configuration in your build logic. If you run the release from a developer machine, this is fine. However, for the most part this is not the case and releasing from the CI server with greater control and traceability calls for the configuration to be part of the job
• With no strong concept of release “action” that Jenkins can understand, there can be no indicators in Jenkins or in the artifacts repository (Artifactory in this case), that a build was in fact released and that artifacts are part of a release
• As with Maven, rollbacks may require manual intervention and running a release build on the server will not reuse Jenkins job’s setting like SCM details, resulting in dual configuration

Meet the Jenkins Artifactory Plugin

Given all that, we at JFrog, decided to pick up the glove and develop a new release and promotion alternative. The Jenkins Artifactory plugin provides a release management plugin that is:

• Lightweight and fast - only 1 compile/test cycle is required 
• Has close integration with your Jenkins exiting configuration, so it reuses the SCM and build settings. The plugin directly integrates with the execution of the Jenkins Maven plugin and the Jenkins Gradle plugin
• Offers very robust and reliable rollback - the plugin is primarily focused on working correctly with GIT and Subversion, respecting the differences between the tools and how tagging and branching is handled in VCS compared to a DVCS, so we don’t have to compromise on a common denominator
• Provides finer control over which properties (in Gradle) or POM versions (for Maven) should change upon release and which ones should also change for the next development cycle
• All commit comments are adjustable and can use Jenkins parameters

When used in conjunction with Artifactory for managing your build artifacts the plugin also -

• Offers advanced control over staging & promotion flow - build artifacts can be staged to a certain repository, and staged artifacts can be either released or rolled-back directly from Jenkins UI with changing of the release status in Artifactory without requiring a rebuild
• Audits all release and promotion actions 
• Makes release builds fully traceable by deploying a build-info json object along with the binary artifacts, with information about: environment vars; all artifacts produced; all effective dependencies used; and even all licenses used by those dependencies
• Allows users to attach custom searchable properties to release artifacts upon deployment

Judging by user feedback, the Jenkins Artifactory Plugin really manages to make a difference by providing Maven users with a better alternative and Gradle users with an integrated Jenkins-side solution, for easy staging and promotion experience which is fast and reliable.

Give it a try now and see for yourself :)

The Jenkins Artifactory plugin can be found on the Jenkins Plugin Center, with the release management specific page here. All sources are on Github under the Apache 2 license.
Expect similar release management support from JFrog in the next versions of the TeamCity Artifactory plugin and the Bamboo Artifactory plugin

The Future of CI at JAX Conf

The Future of CI at JAX Conf - San Jose June, 2011
 by Fred Simon

These are exciting days for Continuous Integration users and for us - JFrog Artifactory team.

Following the successful CI Summit held in LinkedIn HQ last month, we are now heading to the San Jose JAX Conf!
This year, for the first time, the great European JAX conference is going to the Bay Area as JAXConf.
It will be an amazing gathering for our (JFrog) ecosystem.Many players that keep pushing the limit of Continuous Development, Build, Integration and Deployment, with their tools, knowledge and case study will be there:

• Kohsuke Kawaguchi from Cloudbees and Ken Sipe from Gradleware, are getting ready for “Jenkins & Gradle Hackathon”. It’s promising a lot of great features for Gradle and Jenkins users. We will see how our great latest Gradle-Jenkins-Artifactory plugin and clean DSL will improve your day!
• Of course Kohsuke Kawaguchi will present “Continuous Integration with Jenkins”, and it’s always a pleasure to hear and see Kohsuke express his view of CI and how Jenkins is moving the field forward.
• And Ken Sipe will be “Rocking the Gradle” and show this amazing new build tool: Gradle.

The current growth of CI and DevOps is really impressive! The demand is so big that a full afternoon will be dedicated to CI, “The CI Circus” as a free community event.
And there Carl Quinn from Netflix, will present the amazing platform they setup “Netflix in the Cloud”, using Jenkins and Artifactory!

A lot of amazing talks about Continuous Integration, DevOps tools, and automated ALM will be presented:

• “Git Going with a Distributed Version Control System!” by Matthew McCullough, Tim Berglund: The push for a VCS that can answer the need for very short cycles is very strong. Today, Git is really unlocking most of VCS bottlenecks. But it’s well known: “I know git can do it! I just don’t know how to tell it what I want!”. This full day tutorial should help with that issue.
• “Improving the technical quality of your Java project” by Alexander von Zitzewitz from Hello2morrow, will present how to keep project quality over time.
• “Managing Software from Development to Deployment in the Cloud” by Harpreet Singh, Vivek Pandey from Cloudbees: They will present the next generation platform to “build and deploy your apps in the cloud”.

And of course, I’m looking forward to present “You Killed My Build! Prepare To Die!”, were I will demo a state-of-the-art integration between Jenkins, Gradle and Artifactory. The setup support build isolation, release staging and promotion, and simplified developers on-boarding.

Hope to see you all there!