Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are evaluating and setting up Continuous Integration for our PHP project. Each of the Continuous Integration tools has their own proprietary "build language" which will run many commands and check the return status of these commands.

Here is an example of a .travis.yml configuration:

language: php

  - "5.3"
  - "5.4"
  - "5.5"

script: phpunit test

    - sourcespeak@phor.net

A Jenkins configuration will be in XML and is too long to paste here.

Here is an example of a circle.yml configuration:

    - bundle install:
        timeout: 240
          foo: bar
          foo2: bar2

My question is: what is the benefit of using all these popular, proprietary configurations languages for CI instead of using a Makefile to set up your test environment and have whatever CI server just run make test?

share|improve this question

migrated from stackoverflow.com Apr 2 at 19:07

This question came from our site for professional and enthusiast programmers.

I am not sure why you are looking at Jenkins XML files. Jenkins us configured through a web interface without ever needing to go to XML. From the Jenkins web interface, you can configure all aspects of the job, including how to build and run tests. For some jobs I have used qmake, make and invoking a custom executable. Others have invoked msbuild and mstest. All of these were configured through the web interface. –  jwernerny Apr 2 at 19:37
We use typical build stuff (make, rake, msbuild) and layer the CI bits on top of it. They aren't mutually exclusive. –  Wyatt Barnett Apr 2 at 20:21
Jenkins is not a replacement for make. It is a complement. –  whatsisname Apr 2 at 22:14
@jwernerny hmm, I've had to dive into too many config files for systems that were supposedly "maintained by the user interface" but were constantly messed up by that user interface to question someone taking a look at such files and modifying them by hand. –  jwenting Apr 3 at 10:39
@jwenting Jenkins is quite stable and robust. Every system is different, but in over 3 years of working with Jenkins/Hudson on a daily basis, I had to look at a job config's xml exactly 1 one time. And even then, the issue wasn't in the config file. –  Slav Apr 3 at 12:59

2 Answers 2

up vote 11 down vote accepted

What proprietary "build language" in Jenkins? Saying that Jenkins's "build language" is an XML file is like saying your makefile's "build language" is machine code. Not quite, but the gist is the same.

You need not concern yourself with how Jenkins stores it's configuration no more than you would concern yourself with the resultant machine code after your makefile runs. You will never be modifying Jenkins's XML by hand.

Jenkins is a web-based GUI (with cli and web APIs to complete it). The "build language" of Jenkins is whatever you want, from Maven to Ant to Shell and many more in between. It is further augmented with a multitude of plugins that allow you to customize the build flow just as you want it.

And at the end of the day, in Jenkins, your build step will be "Execute Shell" where you will write make test just like you did on command line. The benefits of Jenkins is not executing your build (any scheduler can do that), but organizing and putting everything together, and keeping it accessible to your team through the web.

I can go on listing all the great things that Jenkins will keep track of for you (SCM changes, console logs, test results, artifacts, emails, etc, etc), but you will get a far better overview from any Google search on the benefits/features of Jenkins.

Late edit:
A more elaborate answer on the topic

share|improve this answer

travis-ci is designed to take your script file ( in your case a makefile) and set it up to run on many different versions of your language (in your case php) with minimal setup.

The .travis.tml file is designed to setup everything to run your tests and to run them, in about 5 lines!

It's also designed to be set it and forget it, copy the five lines or so from the documentation, modify them slightly for your needs, and you never have to worry about your CI setup again.

If you run your own CI server it's a lot more difficult to test on different language versions (or change versions on a whim ), see the results in the GitHub UI, and you have to worry about maintaining and updating the server, instead of the 5 minutes setup of a cloud CI service like Travis.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.