User:ElodieAndco/AnthillPro

From Wikipedia, the free encyclopedia
Jump to: navigation, search


AnthillPro
Developer(s) UrbanCode
Stable release
3.8.2 / February 2012
Operating system Cross-platform
Type Continuous Integration, Continuous Delivery, Application lifecycle management (ALM), DevOps
License Proprietary
Website www.urbancode.com/html/products/anthillpro/default.html

AnthillPro is one of the first continuous integration servers. It was released in 2001 and is developed by UrbanCode. As of 2012, AnthillPro has matured into an enterprise integration and delivery[1][2] automation platform that supports continuous integration,[3]:59 deployment automation,[3]:126 application lifecycle management (or ALM),[4] and the emerging DevOps methodology.

AnthillPro supports distributed as well as cross-platform builds in .NET, Java, C/C++, and other programming languages. According to UrbanCode, AnthillPro has over 400 enterprise customers worldwide (as of 2009).[5]

Notes to the editors[edit]

My vision here is to

  • describe the evolution of this tool from its beginnings to its current state
  • present the version history and the features added
  • tie the features added to the various methodologies that they support by and referencing the methodologies as appropriate. -- I don't want a section on CI, CD, ALM, or DevOps here. I just want to show how this tool has evolved and present an accurate view of its feature scope.
  • I want to describe how it works, see the new section "Features and benefits" and, I have a nice graphic for this section = can someone tell me if this is ok? I already checked the copyright, its urbancode, I believe I can get an un-copyrighted version for the article.
  • I want to state benefits, but some of them sound to market"ie" to me - and I am not sure if this is in keeping with wikipedia articles. Please advise. (I didn't write them. Gartner did.) Currently, they are mentioned in passing, sort of.
  • Please add your comments on my talk page.

Historical Perspective[edit]

The evolution of Continuous Integration[edit]

In software development organizations that use Source configuration management,SCM, developers check out code from the main body of code, also called the main code line, to make changes and then check their changed code back into the main code line. After code is checked in, the entire project is "built" and tested.

If no errors are generated during the build process, the build is deployed to a test environment and unit tested to make sure that the quality of the build Project has not been decreased since the previous build. This process of build, deploy, unit test, every time code is check in is called Continuous integration.[6]

The original Anthill was a simple continuous integration server released in 2001 and is still available today. Along with tools such as CruiseControl, it helped provide the tooling backbone of continuous integration practices.[6]

Build/integration cycles become more frequent[edit]

Originally, the term "build" referred to the process of compiling and linking source code into executable code. Typically, these executables would be stand alone applications, for example Microsoft Word, or Adobe Photoshop, etc. During the 1990s the typical release cycle for applications was 12 to 24 months, for example Microsoft Windows operating system.[7]

Software release cycles shortened as Incremental development methods such as Rapid application development, RAD gained acceptance over the Waterfall model approach to software development. In the waterfall model, developers delivered their all their code at the end of the development cycle, then an integration test phase began, followed by bug fixing until the release was judged worthy of the next phase of testing, usually system, or functional testing.

Integration failures that were only detected after the development process was complete led to huge delays and cost overruns. Even worse, integration failures that were not detected during the first integration phase became increasingly expensive to find and fix as they moved through the testing process and into production.[8]

The cost savings of finding these integration failure bugs EARLY in the overall process has been well documented by W. Edwards Deming, Philip B. Crosby and many others over the past 30 years. Briefly, Deming, Crosby and other statisticians and QA thinkers have demonstrated that the cost of fixing errors rises geometrically the farther they move from the initial site on insertion.[9] Compound that with the fact that in a software development project there are typically multiple contributors to the project; the more contributors, the more insertion points for bugs, and hence the complexity of the problem and the cost of identifying and removing these bugs becomes -overwhelming if it is not controlled.

Iterative approaches evolved to meet market demands for faster product delivery, and to avoid the failures of the waterfall methodology. RAD, uses several short development cycles, with fewer features in each development cycle, and more early opportunities to detect integration failures, and more functional test cycles, each building on the last and requiring a regression test to ensure that nothing from the previous release(s) was broken by any new features.

This pattern of checking code in more and more frequently until developers typically checked in code once a day. After all the code was checked in, a build was run, this process is called rolling, or nightly builds.[10] The first test performed is whether or not the code builds successfully. Beyond that, a series of unit tests, and general functions tests, commonly referred to as "smoke tests" can be run. Ideally both the build and the tests are automated, so that a quality assessment can take place quickly. If any of the tests fail, the build fails and must be fixed immediately. If the tests pass, then the build might be deployed to a test system for the test group to conduct the first phase of their testing.[11]

Build/integration of applications becomes more complex[edit]

With the advent of multi-tier architectures, beginning with client-server, and progressing to Service-oriented architecture,SOA, a build has become potentially much more complex than simply compiling and linking code or some dynamic interpreted language variation. It may include many other types of activities, for example, applying database changes, loading static content from a Content management system, CMS, configuring software components, testing, and deploying all or part of the build.[12]:4

Prior to the release of AnthillPro, UrbanCode had released the original Anthill OS,[13]:397-401[14]:275-278 a free tool intended for build management. Due to the success of Anthill OS, AnthillPro was created as a commercial alternative.[12]:360 In 2002, UrbanCode released the first commercial edition of AnthillPro. Unlike CruiseControl, which at the time was focused purely on providing developers feedback about the health of their builds, AnthillPro was focused on build management and using the results of one project's build as a dependency for other projects.[15]

Application release cycles shrink - Build cycyles become more frequent[edit]

In addition to the growing complexity of the build / release cycle, the typical release cycle for software projects has shrunk and continues to shrink radically.[16][17]

As Agile methodologies have become more commonly practiced, the pace of integration and build has changed from once a day to, every time there is a code change. The reason for this is that in Agile, the main line of code should be ship-able at any time. It does not need to be feature complete but it must be of sufficient quality to be releasable.[12]:49

AnthillPro supports this practice[6] by monitoring (or listening to) the organization's various source control systems and triggering a build when it detects a developer commit. The build provides the first (and usually the most critical) test that verifies the integration. Once the build is complete, AnthillPro captures the build product so that secondary processes like functional tests or deployments to manual QA areas can act on the build. As additional tests are executed, the team can gain greater confidence in the changes.

Automated Deployment[edit]

Software deployment becomes more complex and more time consuming to produce, test and deploy, with private networks using Client server architectures and web based applications using the internet. In the race to produce more ship-able applications faster, more and more developers begin to use more automated tools to build and test their software on a daily basis. CI raises expectations on how fast the software can be developed and delivered. Continuous Integration allows developers to prepare releases of individual applications faster and faster, but deploying the releases (mostly done by operations groups) has remained manual, time consuming, and unreliable. Deployment has become more complex as multi-tiered applications, especially web applications become more popular. Instead of simple deployments that deploy only one application at a time, now several layers of the system may need to be deployed in a coordinated multi-threaded workflow. For example: a typical web application will have at least 3 layers, the static html and CSS content, applications that run at the web server level, and a database where all the application data is stored. Developers of applications were the most likely to use Continuous Integration, since it is focused on collecting items that developers have checked in that are needed for the build, building / compiling them into binary files (executables), storing them in an artifact repository, then copying them to a test environment where unit tests and possibly function tests, or smoke tests, can be run to verify that the quality of the build is satisfactory. CI was not used to organizes the static content, or data base changes; like stored procedures, and table changes.

Additionally, human testers are conducting manual tests on the software once it is deployed, further slowing the movement of software towards production - together manual testing and deployment become an obvious, expensive bottleneck in the development process.

Agile software development responded initially with "Extreme Programming" [Kent Beck]. Asserting that development can do the testing and that traditional manual testers only slow things down. As a result, Deployment and Quality Assurance were taken over by developers in some cases, leading to very poor quality software being released by shops practicing Extreme Programming. Development efforts that retained manual test cycles suffered from the imbalance of developers capable of turning out a new code for testing several times per day, and slow manual deployments and test cycles forced to run man hours of regression tests on every code turnover. --becoming a huge and resented bottleneck in traditional incremental development efforts.

Continuous Delivery[edit]

In 2011 several enterprises are reporting that they have achieved continuous delivery of software.[citation needed] This accomplishment is the product of refined and codified delivery pipeline process supported and implemented in an automation framework. Manual processes which are slow and error prone due to their repetitive nature, are minimized.

History[edit]

The original Anthill was a simple continuous integration server released in 2001 and is still available today. Along with tools such as CruiseControl, it helped provide the tooling backbone of continuous integration practices.

Prior to the release of AnthillPro, UrbanCode had released the original Anthill OS,[13]:397-401[14]:275-278 a free tool intended for build management. Due to the success of Anthill OS, AnthillPro was created as a commercial alternative.[12]:360 In 2002, UrbanCode released the first commercial edition of AnthillPro. Unlike CruiseControl, which at the time was focused purely on providing developers feedback about the health of their builds, AnthillPro was focused on build management and using the results of one project's build as a dependency for other projects.[15]

In 2006, UrbanCode released the third generation of AnthillPro.[18] This complete rewrite added support for distributed builds, and control over post build lifecycle. Unlike most CI servers that are build centric, AnthillPro began to use the build only as an initial test and to create binary artifacts that are then tested, deployed and promoted through a lifecycle on their way to production release.

AnthillPro version 3.6 (released in 2008) extends the toolset to Application lifecycle management (ALM)[19] using centrally managed automation for build, deploy, and test. The release adds integration for numerous 3rd party ALM point solutions, such as artifact repositories, SCM, issue-tracking, test-automation, change management systems and project management systems.[20] Other new features supporting this consolidation include detailed review of historical test results, flexible resource locking, and pre-flight builds.[21]

AnthillPro version 3.7 (released in 2009) increases AnthillPro's ability to integrate with other point tools in the Continuous integration, Build Automation, and ALM space. New features adds integration plugins for seven of the most widely used source code analysis tools to the 50 existing integration plugins, new repository and database integrations and the release introduces a new plug-in API that allows users to create their own custom integration plug-ins.[22] This release also introduces the AHPTool that allows users to create script actions from the command line and access data in the AnthillPro repository. Agent User Impersonation gives administrators greater control over scripts run by agents.[23]

AntHillPro features and benefits[edit]

original gartner paragraphs[edit]

"AntHillPro Why Cool: Urbancode has two products that address release automation. AnthillPro includes both build and release capability. UrbanDeploy is a new solution that is focused on application release capability (a subset of AnthillPro), but has broader deploy capability. AnthillPro is based on an open-source product called Anthill OS, but adds release capability. Both include comprehensive modeling and workflow capability. One key benefit of this tool is how quickly it can be implemented and used for deployments. Most tools require complex setup. Its workflow engine enables application modeling and the ability to tailor multitier applications, with extensibility of configuration settings by environment. It can also be used to deploy application binaries. The workflow enables tracking of the release management execution of process steps within a single environment and across multiple environments. Configurations are externalized from the applications and are reassociated with the appropriate environment (build, test, quality assurance, production, etc.), enabling a flexible application deployment model. Traditional deployment is often a lengthy and complex process, with custom scripts and long handoffs times. This can now be accelerated through automation of the modeling and execution tasks, which is available in Urbancode's AnthillPro and UrbanDeploy. It can integrate at an API level, interfacing to external tools, or at a data level, where it executes tasks for various activities across the tiers. Both tools offer a wide variety of out-of-the-box plug-ins to established development tools (source code and build), as well as test tools."

my take paraphrasing on this quote and others[edit]

  • supported by Gartner quotes for benefits 2011 (from 2011 Cool Vendor Award) Several other references in my pipeline too (5 other Gartner articles)

According to Gartner[x], AnthillPro offers several key benefits in continuous integration, automated deployment, ALM and DevOps. It can be integrated quickly and used for build, test and deployment. Most tools require complex setup. AnthillPro’s workflow engine enables application modeling and the ability to tailor multitier applications, with extensible configuration settings on a per-environment basis. The workflow enables tracking of the release management execution of process steps within a single environment and across multiple environments. Environment configurations are externalized from the applications and are reassociated with the appropriate environment (build, test, quality assurance, production, etc.), enabling a flexible application deployment model. AnthillPro’s automation of continuous integration and automated deployment coupled with its extensive integrations with (third party) build, test, and deploy tools create a flexible automation framework which make it is possible generate large time savings, improved efficiency, repeatability, and reliability in the delivery pipeline.[lots of citations]


end Gartner quotes for benefits

Example to explain what gartner was saying[edit]

--Note to self: Verify that this example detail is correct for AnthillPro…and cite source

For example, a web application might have three tiers; static web pages, web application, and database. Each of these tiers will have an AnthillPro component and each component can be deployed to a different environment. This collection of components in their environments is characterized as an application. Components in the application can be deployed individually or in combination and each environment that a component is deployed to can have its own configuration.

So, a development test environment may deploy the web content, application, and database in a single virtual environment. The QA environment may be spread across several machines, the UAT environment may be a shadow of the production environment, and the production environment may have multiple servers, load balancing, and distributed data bases and so on. All of the differing environments and configuration requirements can be automated in the workflow.

  • End Example------------------------------

Product Evolution: Continuous integration[edit]

Note: this section needs to be fitted into the early AnthillPro discussion and be a section no more----------- The practice of continuous integration is one where developers integrate their changes to a common code line frequently (generally at least once a day) and those integrations are rapidly verified by tests. AnthillPro supports this practice[6] by monitoring (or listening to) the organization's various source control systems and triggering a build when it detects a developer commit. The build provides the first (and usually the most critical) test that verifies the integration. Once the build is complete, AnthillPro captures the build product so that secondary processes like functional tests or deployments to manual QA areas can act on the build. As additional tests are executed, the team can gain greater confidence in the changes.

Features[edit]

Feature:Reporting[edit]

AnthillPro can gather any reports generated by build or test process and display them on the AnthillPro server's web interface for review by developers, testers or management.[20]

Reporting is way more exciting than this. every single step has report attached to it if the process has a log or error log, it is attached. finding failures is marvelously simple, click on a red icon next to the step, and the appropriate interface opens (cmd, browser, or whatever) and the report is displayed. AnthillPro's interface takes you all the way through every step, success, failure, or compliance / non compliance. lots of outcome possibilities. this feature has not been covered well in the media. I wouldn't know it if I hadn't seen it.

Feature:Deployment automation[edit]

AnthillPro supports automated deployment[24] of a build to a user-configured environment (for example: DEV, QA, STAGE, PROD). Administrators can set up gates between each environment, requiring manual user intervention and providing an audit trail.[3]:255 Role-based security can be set up to control what roles (and thus what users) can deploy to which environment.

Feature:Integration with external systems[edit]

As AnthillPro transitioned from a continuous integration server to an automation framework capable of complex deployments,[12]:264-266 UrbanCode began expanding AnthillPro's capability to integrate with 3rd party tools (out-of-the-box). According to Gartner (2011),[25] AnthillPro can integrate at an API level, interfacing to external tools, or at a data level, where it executes tasks for various activities across the tiers. AnthillPro offers a wide variety of out-of-the-box plug-ins to established development tools (source code and build), as well as test tools. AnthillPro version 3.8.2 released in February 2012, integrates with over sixtyEmpty citation (help)  3rd party products, including J2EE Servers, Databases, Build Systems, EAI and BI, Infrastructure, and the Microsoft Platform. Additionally, AnthillPro supports the external plugins that extend its automation framework to accommodate virtually any software that can be driven from the command line.[23]

Feature: Release management (major contributor to ALM)[edit]

UrbanCode has won several awards based on AnthillPro's release management capabilities.Template:Add my citations back in AnthillPro is designed to support the release management[26] team's efforts. It provides an audit trail linking a build back to source code and to every deployment and test executed against that build. This helps a release manager asses the readiness of a build to enter production. AnthillPro encourages teams to use a similar automated process for production deployments to those used in earlier environments lowering the risk in a deployment through testing the process.

The built in Artifact repository ensures that a artifacts are not changed or tampered with as the application moves through the delivery pipeline. Ensuring that the version that is released is the version that was tested.[citation needed]

This is also where we should talk about approvals and governance. the workflow can incorporate all of the sign-offs, and responsible parties in an automated form. Send out emails, ask for approvals, etc.

Awards[edit]

  • 2007 Dr. Dobb's JOLT Change and Configuration Management Productivity Award[27]
  • 2011 Gartner Cool Vendor Release Management Award[25]

References[edit]

  1. ^ Minick, Eric (2011). "Enterprise Continuous Delivery Maturity Model" (PDF). UrbanCode. p. 14. Retrieved February 17, 2012.  Unknown parameter |Author= ignored (|author= suggested) (help)
  2. ^ Julius, Paul (September 11, 2009). "Enterprise CI Cultural Maturity". UrbanCode Blogs. UrbanCode. Retrieved February 17, 2012. 
  3. ^ a b c Humble, Jez (2010). Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (3rd ed.). Addison Wesley. p. 463. ISBN 978-0-321-60191-9.  Unknown parameter |coauthors= ignored (|author= suggested) (help); More than one of |author= and |last= specified (help)
  4. ^ SD Times News Team (September 1, 2008). "True Application Life-cycle Management With Urbancode". SD Times. Retrieved February 3, 2012.
  5. ^ "Urbancode's AnthillPro Reaches Milestone 400th Customer in Company's Strongest Quarter" (Press release). Cleveland, Ohio: UrbanCode. December 7, 2009. Retrieved February 10, 2012. 
  6. ^ a b c d Roebuck, Kevin (2011). Continuous Integration: High-impact Strategies - What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors. Emereo Pty Ltd. p. 134. ISBN 9781743044841. 
  7. ^ MSDN (January 18, 2007). "PRJ: Microsoft Project for Windows Version History". Article ID: 98026 - Last Review: January 18, 2007 - Revision: 3.1. MSDN. Retrieved March 14, 2012. 
  8. ^ Crosby, Philip B. (1979). Quality is Free. New York: McGraw-Hill. ISBN 0-07-014512-1. 
  9. ^ Quality is still free: Making Quality Certain in Uncertain Times. New York: McGraw-Hill. 1996. ISBN 0-07-014532-6. 
  10. ^ "Nightly Builds: the bleeding edge". mozilla. mozilla.org. 2/1/2011. Retrieved March 01, 2012.  Check date values in: |access-date=, |date= (help)
  11. ^ "Iteration Activities Rolling and Nightly Builds". MSDN Library. 2/7/2008. Retrieved March 01, 2012.  Check date values in: |access-date=, |date= (help)
  12. ^ a b c d e Duvall, Paul M. (June 2007). Continuous Integration: Improving Software Quality and Reducing Risk. Upper Saddle River, New Jersey: Addison-Wesley. p. 283. ISBN 0321336380.  Unknown parameter |coauthors= ignored (|author= suggested) (help)
  13. ^ a b Hatcher, Erik (2003). Java Development with Ant: How to automate your build, test and deployment processes. Greenwich, CT: Manning. p. 634. ISBN 1-930-01058-8 Check |isbn= value: checksum (help).  Unknown parameter |coauthors= ignored (|author= suggested) (help)
  14. ^ a b Larman, Craig (2004). Agile & Iterative Development: A Managers Guide. Boston, MA: Addison-Wesley. p. 342. ISBN 0-13111155-8. 
  15. ^ a b Clark, Mike (July 1, 2004). Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications. USA: Pragmatic Bookshelf. p. 176. ISBN 978-0-9745-1403-1. 
  16. ^ Bradley Holt (August 8, 2011). "The Case For Rapid Release Cycles". Bradley-Holt. Retrieved March 14, 2012. 
  17. ^ Versionone (2012). "Release Planning". Customer and Management Practices. Versionone. Retrieved March 14, 2012. 
  18. ^ Minick, Eric (October 26, 2006). "Urbancode announces AnthillPro 3.0, lifecycle automation server". TheServerSide.com. Retrieved February 22, 2012. 
  19. ^ Rubinstein, David (November 4, 2011). "Agile processes adopted widely, study shows". SD Times. Retrieved February 11, 2012. 
  20. ^ a b Dr. Dobb's Journal (January 27, 2008). "Urbancode Releases Continuous Integration Tool Upgrade". Dr. Dobb's. Retrieved February 14, 2012. 
  21. ^ Dr. Dobb's Journal (October 28, 2008). "UrbanCode Adds Pre-Flight Builds”. Dr. Dobb's. Retrieved February 10, 2012.
  22. ^ "AnthillPro 3.7 Released". Agile Journal. October 5, 2009. Retrieved February 14, 2012. 
  23. ^ a b Feinman, Jeff (October 9, 2009). "Command-line features added to AnthillPro". SD Times. Retrieved February 14, 2012. 
  24. ^ Sayko, Michael (September 15, 2008). "Using a Commercial Tool to Automate a Build and Deployment Process". CM Crossroads. Retrieved February 3, 2012.
  25. ^ a b Colville, Ronni J. (2011). "Cool Vendors in Release Management, 2011". Gartner. Gartner. Retrieved February 23, 2012.  Unknown parameter |coauthors= ignored (|author= suggested) (help)
  26. ^ "Release Management". Wikibooks. Retrieved February 10, 2012.
  27. ^ Wyser, Della (March 13, 2007). "Jolts 2007: Change and Configuration Management". Dr. Dobb's Journal. Retrieved February 13, 2012.  Unknown parameter |coauthors= ignored (|author= suggested) (help)

External links[edit]

Blogs and help sites[edit]


Category:Continuous integration]] Category:Configuration management]] Category:Build automation]] Category:Software programmed in Java]]