I've gotten several questions in the last few weeks about Taskotron and how it compares to Jenkins. With the rate at which I'm getting that I'm getting these questions, it's a topic well worth exploring.
Unfortunately, "How does Taskotron compare to Jenkins?" is a difficult question to answer because it's not a very valid comparison. The question is similar to comparing the apple press (used to make juice) in one factory with the entire apple juice factory across the street - they're not totally dissimilar but they definitely aren't the same thing either.
What is Taskotron?
Taskotron is a modular system designed to make automation easier for a semi-arbitrary set of people without forcing anyone to use the entirety of a single stack (after setup, libtaskotron doesn't care what the rest of the job is written in so long as it returns a form of output it understands).
To really understand what Taskotron is, let's take a look at how it fits into Fedora's infrastructure and build process.
Pretty much anything going into or coming out of Fedora's Taskotron instance is in the form of fedmsgs because that's what everything in Fedora uses but there isn't much more code needed if one wanted to move that to AMQP or another messaging protocol.
Looking a bit closer at the "Taskotron" box in that diagram, the "trigger", "execution" and "results" stages can be decomposed a little farther.
I do want to call attention to a few things in this diagram:
We didn't go straight to full on insanity and write everything from scratch. Buildbot is an important part of our deployments
Buildbot is relatively isolated - there is little custom code in our buildmaster configuration (current template as of this writing) to make sure that we have hard coupling in as few places as we can get away with.
The cloudy "stuff" in this diagram is vague by design - libtaskotron doesn't care whether the detailed bits are written in Python, Perl, C, C# or whatever, so long as it can be run on the clients and returns something that it understands (ResultYAML, xUnit etc.)
Libtaskotron is talking to ResultsDB and the "stuff" which gives us the following advantages:
- There is a single point through which all results pass, if the ResultsDB interface changes or we need to start reporting to something else, that change will be about as painless as it could realistically be.
- The "stuff" doesn't have to know where it's sending results, it just needs to output a known and well defined format which means less extra futzing and testing for the people maintaining that "stuff".
- By having looser coupling with the execution framework (Buildbot in this particular case), it's possible to have close to identical execution environments locally on a developer's machine or in a production Taskotron deployment.
What is Jenkins
As stated on their homepage, Jenkins is "The leading open source automation server" and while differences between the two are numerous, plain upstream Jenkins fits roughly in the same box as Buildbot from the previous diagram.
How are Taskotron and Jenkins Similar?
When we're talking about plain, upstream Jenkins, the short answer is "they aren't very similar at all". That being said, if you change the question a bit to "How does Taskotron compare to my Jenkins instance which has this custom config and these plugins which may or may not be commonly available?" then there's a bit more potential for similarity but that's a very difficult question to answer without knowing which plugins are being used and how the Jenkins master is configured.
Coming back to my earlier analogy about apple presses and apple juice factories, upstream Jenkins or Buildbot would be the apple presses for making juice and Taskotron is the juice factory.
Closing Thoughts
This is scratching the surface of the current state of Automation in Fedora from a QA perspective and there are plenty of more topics to cover on the topic which I plan to start covering in more regular posts here. That being said, I do want to end with some of the design goals for Taskotron to give a little more context to some of the reasoning which has affected our decisions so far:
- Keep components as loosely coupled as possible while remaining sane
- Users should be able to closely simulate the production environment with little to no effort.
- Taskotron itself should be as generic as we can sanely make it. Most users in Fedora should be able to automate tasks with taskotron more easily than worrying about setting up and maintaining their own system.
- The Taskotron devs are not experts in testing all of the things, our goal is to make the common, tedious crap easy for users and then get out of their way so they can focus on the bits they're working on instead of fiddling around with automation.