Continuous builds for open source projects

At ElephantScale, we practice what we preach. Here is one example. Our FreeEed project is open source eDiscovery, and it is popular with lawyers, legal tech, and data researchers. We apply continuous build (CI) to it: every time there is a commit to the developer branch, this causes a Jenkins build. This allows us to feel good about the project being stable and passing all the tests.

But we go beyond that. Amazon AWS allows you both source code control, in the form of CodeCommit, and Jenkins-like Continous Integration, in the form of CodeBuild. We teach AWS, so of course, we investigated this approach too. However, we did not want to move FreeEed from GitHub – it is already quite popular there. The options of doing CodeBuild with Git included replication or giving away our credentials, and we did not want either. We want to just pull from GitHub since the project is open source. Not having found a way, we built our own.

Our next step is to add a new level of functionality to FreeEed: we want to make the tool scriptable. FreeEed started out as a command line tool; then we added UI for usability. But now we get more and more request to add scripting capability. But here is the joy: we will add JUnit system tests that will run those command-line options after the release jar is build. This amounts to testing the released code. Thanks to all who contributed!

Mark Kerzner
Written by:

Mark Kerzner

Mark Kerzner is the co-founder of Elephantscale. He is a Trainer, Author(AI, Machine Learning, Spark, Hadoop, NoSQL, Blockchain)

Leave a Reply

Your email address will not be published. Required fields are marked *