Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Ant, Maven, Rake etc What are build tools all about?

Options
  • 05-12-2013 6:56pm
    #1
    Registered Users Posts: 121 ✭✭


    Why do developer teams use Build Automation Tools, surely whatever IDE you are coding in will build your project?

    I've read up on what Ant and Maven etc do, and how they work, but I still can't wrap my head around why you would ever need them, when your IDE builds your project for you anyway!


Comments

  • Registered Users Posts: 1,311 ✭✭✭Procasinator


    Because sometimes you need to build outside of the IDE, or don't even use an IDE in the first place.

    In summary, build scripts automate building, whereas you opening an IDE and hitting build is not automatic, even if simple.

    Some examples of why you might want to automate builds:

    The most basic reason you might have a build script is for projects that have releases, especially when there is multiple target platforms. Instead of somebody opening an IDE and building each configuration, they kick of a build script and let it do all the hard work. Imagine offering nightly beta releases for something like Chrome, Firefox or even the linux kernel, and someone had to build each target for each OS every night in the IDE.

    Continuous integration is another reason you may want a build script. Typically, this works on a schedule or whenever someone commits to version control. It can verify the build is still working, and run all tests, and other tasks (static analysis, test code coverage reports, etc). This keeps everything in check, and alerts everyone when something is amiss in the repository.

    Some people even do continuous deployments, where once something is committed into a production branch, a hook will kick of the build script and deploy the new code to production.


  • Registered Users Posts: 121 ✭✭IS_a_Class



    Continuous integration is another reason you may want a build script. Typically, this works on a schedule or whenever someone commits to version control. It can verify the build is still working, and run all tests, and other tasks (static analysis, test code coverage reports, etc). This keeps everything in check, and alerts everyone when something is amiss in the repository.

    Well that sounds pretty handy, as does the rest. Thanks a mil


  • Registered Users Posts: 121 ✭✭IS_a_Class


    Cool picture


    build-system-evolution13.png?w=551


  • Registered Users Posts: 7,157 ✭✭✭srsly78


    And then to really confuse the OP there are tools like cmake, which are meta build tools, it can "make" the make files :D

    Talking about it is a poor substitute for experience tho, go install jenkins and start automating your builds. All free!!!

    http://jenkins-ci.org/

    Best used on linux imo. If you are a windows monkey go "acquire" vmware workstation first. This is handy if you want a personal linux server to mess around with, without the hassle of dedicated hardware.


  • Registered Users Posts: 4,768 ✭✭✭cython


    srsly78 wrote: »
    And then to really confuse the OP there are tools like cmake, which are meta build tools, it can "make" the make files :D

    Talking about it is a poor substitute for experience tho, go install jenkins and start automating your builds. All free!!!

    http://jenkins-ci.org/

    Best used on linux imo. If you are a windows monkey go "acquire" vmware workstation first. This is handy if you want a personal linux server to mess around with, without the hassle of dedicated hardware.

    Or virtualbox is generally adequate for most people either.

    OP, to be honest, the answer is in the question you asked, i.e. "Why do developer teams use Build Automation Tools, surely whatever IDE you are coding in will build your project?" While there is a use of the tools for individuals, they really come into their own in team environments. Procastinator covered most of the reasons for build tools, but several others would be:
    • The "it works on my machine" principle - Lots of people set up their IDEs slightly differently, and while project files can be tried to be maintained the same, build tools are more easily kept as a common denominator, and can be deemed the defacto. Further, build tools can be used to generate workspace files for projects (e.g. mvn eclipse:eclipse), while being neater to keep in version control
    • Test automation - while you can run your tests from within your IDE, sometimes it is more straightforward to batch run them with the build tool
    • IDE launches can be SLOW!
    • General automation (already mentioned) of what might be called non-primary build tasks
    • Performing tasks that aren't needed locally - e.g. where I work, devs' local environments run on JBoss, but we build and ship artifacts for WebSphere and Weblogic. This is only required on the CI server, and devs have no need to build the latter two, but without maven (in our case) someone would have to be nominated to build them from time to time, or devs would be required to do it for each of their changes (wasted manual effort).
    • Shared artifact repos. If you use something like Nexus or Artifactory to host an artifact repository, then build tools can automate publishing of artifacts there (especially in house libraries/dependencies), whereas the alternative with an IDE is probably to make them check out and build each project one at a time - major PITA on large projects

    The list goes on, but I'm sure you get the idea already


  • Advertisement
  • Registered Users Posts: 1,082 ✭✭✭Feathers


    cython wrote: »
    If you use something like Nexus or Artifactory to host an artifact repository, then build tools can automate publishing of artifacts there (especially in house libraries/dependencies)

    & then you've external tools/libraries that are being developed for distribution: if I have a testing tool that runs on top of JUnit, let's say — it's much easier for my code to say "needs JUnit 4 or above", than to build a JUnit JAR into my library.

    If I did that instead, 1) You'd be downloading a binary that you already had and 2) if you used JUnit elsewhere in your project, you'd end up with a painful clash of versions.

    If I did't include it, you'd have to go off & find a version. Maven, etc. gets rid of this problem. My code just says "make sure there is a version of X available", if that in turn needs "Y", it looks after this resolution for you.


  • Registered Users Posts: 2,021 ✭✭✭ChRoMe


    IS_a_Class wrote: »
    surely whatever IDE you are coding in will build your project?

    Yes, by using the aforementioned build tools!


  • Registered Users Posts: 121 ✭✭IS_a_Class


    ChRoMe wrote: »
    Yes, by using the aforementioned build tools!

    do you mean like how Android Studio uses Gradle?


  • Registered Users Posts: 26,578 ✭✭✭✭Creamy Goodness


    IS_a_Class wrote: »
    do you mean like how Android Studio uses Gradle?
    He means that when you click the 'build' button in your IDE it runs the same build tool underneath essentially. Only difference is one is manual other is automatically done based on a set of defined rules (last checkin, time/date based, etc.)


  • Registered Users Posts: 40,038 ✭✭✭✭Sparks


    IS_a_Class wrote: »
    Why do developer teams use Build Automation Tools, surely whatever IDE you are coding in will build your project?
    IDE? :)
    Some projects are so large that IDEs just choke. They'll kindof cope, but be much slower than just using a non-integrated development environment (ie. seperate editor, debugger, build tools).

    And what do you think is happening when you hit the build key in your IDE anyway? :D

    You want to understand programming better, and be a better programmer?
    Dump your IDE and learn to do stuff at a lower level. Even if you never dump the IDE when doing your day job, knowing what's happening behind the scenes will make you better at that day job and make that day job easier on you.


  • Advertisement
  • Registered Users Posts: 40,038 ✭✭✭✭Sparks


    Also, having direct access to the build tools makes some tasks (like running nightly builds on a faster server and then running through automated testing and having a report on the state of the build in your email in the morning to read over your coffee) possible, if not always trivial.


Advertisement