Urbancode announces AnthillPro 3.2.0

Discussions

News: Urbancode announces AnthillPro 3.2.0

  1. Urbancode announces AnthillPro 3.2.0 (7 messages)

    The AnthillPro team is pleased to announce AnthillPro version 3.2.0. AnthillPro goes beyond continuous integration, delivering build and application lifecycle management. This release was focused on better security and easier configuration. We also expanded the range of options for selecting agents to run jobs on and determining the success or failure of a step. New integrations with ClearQuest and MKS Source Integrity are also exciting. Tighter Security AnthillPro now allows mutual SSL authentication between the server and all agents. Agents can be configured to no longer listen for incoming connections, thus eliminating the possibility of an entire class of potential security threats. In addition, AnthillPro 3.2 includes integrations with all commonly used authorization systems such as LDAP, Active Directory, Kerberos, Single Sign-on, as well as custom authorization systems (supported via JAAS). Other Notable New Features
    • Improved installation
    • Choice of Derby or Oracle back ends
    • More flexible execution of command line commands
    • Windows Vista Support
    • Future upgrades of agents will be automatic
    • Streamlined Clearcase (Base) configuration
    • Cancel (abort) build requests and queued builds
    • Circular dependencies detected and rejected at configuration time
    • Digest files holding hashes of all files in an artifact set are available for download.
    • Support for artifacts larger than 2 GB added

    Threaded Messages (7)

  2. Why do we need AnthillPro when there is Maven?
  3. Fair question Neal. Maven is responsible for running the builds, and can still be used from within Anthill. But there are a few more things that you need. First, you need an authoritative build server. If you are publishing builds done by Maven done on a developer machine, your build can be affected by whatever junk is on the developer's machine or whatever hack she put in placed to make the build work while trying to solve some problem. I know I wouldn't trust a build done on my machine for anything more than testing prior to commit. Anthill does the authoritative builds by checking out your source, running the builds, and capturing reports and artifacts. Then, it's important to track your previous builds so that when a customer finds a problem, (or QA) you can easily track that back to the sources it was built from, see how it fared in automated tests, and who from your team pushed it out into production. Getting constant feedback back to your developers about the state of the most recent build is also important. On the dependency management side of things, Maven does a very good job with 3rd party libraries. It does a less good job with internal components that are being developed in parallel. It can be difficult (I think) to see which of builds of which projects happen to use version 1.2.3 of some internally developed component. The promotion model of artifacts within the repository is also pretty weak. Lots of Maven teams stick with the Maven dependency scheme within an Anthill setup, so that works too. Then there's all the promotion and deployment functionality that is usually out of Maven's scope. Does that answer the question at all?
  4. Re: re: Why not maven[ Go to top ]

    I am not sure that maven doesnt already offer a solution to all the issues you mention. For starters, maven's continuum subproject provides an out-of-the-box continuous integration server.
  5. Re: re: Why not maven[ Go to top ]

    I am not sure that maven doesnt already offer a solution to all the issues you mention.
    For starters, maven's continuum subproject provides an out-of-the-box continuous integration server.
    The list of differences between AnthillPro and a tool like Maven is quite large (definitely too large to provide an exhaustive list here). The main differences are listed below: - AHP has a distributed central server and agent model. This has pretty big implications since it implies that AHP can perform distributed and multi-platform builds. It also means that the UI is going to continue to be responsive while there are CPU intesive builds going on. - AHP contains an embeded busines proces engine allowing users to design processes that are to be automated. This provides a lot of flexibility allowing each user to customize the build process in fine detail. This also allows user to design additional processes such as running automated functional, integration, and other tests including sitributed stress tests. - AHP automates the entire lifecycle, not just the build. This goes along with the previous point -- the embedded busines process engine. Processes throughtou the entire lifecycle can be automated without using different build types. This enhances traceability from artifacts back to source (through all the lifecycle stages) and improves traceability. Before you argue this point, I urge you to look into the details. - AHP is not maven specific. If you are a Java and Maven centric team this is not a big deal. But if you're like most of the organizations that we come across, then you not only use Java but have some C/C++, perhaps .Net code and maybe even some Perl or Ruby code. And even on Java, you probably are not tied exclusively to Maven but also use Ant, and perhaps even other build tools. AHP, being cross-platform, supports pretty much every build tool out there; Maven, obviously supports only Maven :) - AHP has a much more sophisticated and powerful dependency management system. Yes, maven handles dependencies. But realistically, the dependency handling within Maven is very simplistic and rather unsophisticated. It may suffice for a simple project team, but does not offer the types of features that are required on larger development efforts. AHP contains a much more sophisticated dependency management system that is accessible by the developers at development time via IDE plugins, Ant tasks, and CLI. Implementing a robust dependency system is actually a tough problem -- if you disagree then I'd claim that you haven't really thought about the problem in much depth. The Anthill team has been working on this issue since the first Anthill release in 2001 -- long before there even was a Maven. Yes, I know, you're going to furiously argue the point about dependency management. I only urge you to look into the details here and actually spend some time thinking about this problem/solution instead of focusing only on crafting a response making wild and unfounded claims based on marketecture. And arguements that go something like -- I've been using tool X for 2 years and it suffices -- are not very convincing. In order for such an argument to be convincing you'd need to demonstrate that your requirements for tool X are a superset of the requirements that anyone else can have -- in that case, the (it meets all my needs) argument would actually carry some weight. I think the above list of differences should be sufficient to answer the point raised in the previous post. As I said, this is not meant to be an exhaustive list. Whether you choose to use, evaluate, or even look into the tool (AHP) is your choice -- certainly no one can force you to do any of that. But, you should give due credit to tools that are outside your existing toolbox, not because its the "nice" thing to do (I'm not always nice either), but because it's the smart and pragmatic thing to do. I often find tools that do a particular job more effectively than a tool that I'm already using. Refusing to acknowledge that is sort of like sticking your head in the sand (or someplace else :)
  6. Re: re: Why not maven[ Go to top ]

    Yes, I know, you're going to furiously argue the point about dependency management. I only urge you to look into the details here and actually spend some time thinking about this problem/solution instead of focusing only on crafting a response making wild and unfounded claims based on marketecture.
    cool down, friend. I dont read anything hostile in my post, and I am certainly far from being a maven fanatic (go ask some of my colleagues)
    Whether you choose to use, evaluate, or even look into the tool (AHP) is your choice -- certainly no one can force you to do any of that.
    I am really glad to hear that ;-). Thank you. Christian
  7. Re: re: Why not maven[ Go to top ]

    cool down, friend. I dont read anything hostile in my post, and I am certainly far from being a maven fanatic (go ask some of my colleagues)
    True enough. I guess I was anticipating a Maven zealot type of response. Sorry. --Maciej
  8. If your software production process ends with a built artifact, you don't. Ant or Maven, whichever one you like more, will work for you. If your software production process extends to actually delivering/deploying a set of artifacts with complex dependencies on each other and third party artifacts, AND you need traceability to prevent problems - as opposed to reacting to problems after the fact - you need the flexible workflow and distributed continuous integration environment provided by AntHill Pro.