Developer(s) | IBM |
---|---|
Stable release | 5.0.0 / September 2013 |
Written in | Java |
Operating system | Cross-platform |
Type | Continuous Integration, Continuous Delivery, Application lifecycle management (ALM), Application release automation, DevOps |
License | Proprietary |
Website | developer |
AnthillPro is a software tool originally developed and released as one of the first continuous integration servers. AnthillPro automates the process of building code into software projects and testing it to verify that project quality has been maintained. Software developers are able to identify bugs and errors earlier by using AnthillPro to track, collate, and test changes in real time to a collectively maintained body of computer code.
AnthillPro was released in 2001. In 2006, AnthillPro expanded into an enterprise integration and delivery [1] [2] automation platform supporting continuous integration, [3] : 59 deployment automation, [3] : 126 application lifecycle management (ALM), [4] and the emerging DevOps methodology. [5]
AnthillPro supports distributed and cross-platform builds in .NET, Java, C/C++ and other programming languages. AnthillPro had over 400 enterprise customers worldwide as of 2009. [6] UrbanCode was bought by IBM in April 2013. [7]
On August 28, 2017, it was announced that AnthillPro is being retired and will no longer be supported after October 31, 2018. [8] It is replaced in the market by IBM UrbanCode Build and IBM UrbanCode Deploy.
In software development organizations that use Source Configuration Management (SCM), developers first analyze and remove code from the "main code line," which is the main body of code. The developers then change the removed code and embed the altered code back into the main code line, which is a process referred to as "checking in." After the code is checked in, the entire project can then be built and tested.
If there are no errors generated during the build process, the build is deployed to a test environment and unit tested to ensure that the quality of the project has not decreased since the previous build. This process of "build, deploy, unit test" for every occasion of checked-in code is referred to as continuous integration (CI).[ citation needed ]
The original Anthill software tool, released in 2001, was a simple continuous integration server and is still available today. Along with tools such as CruiseControl, Anthill contributed to the establishment of standard tools for continuous integration practices. [3]
Originally, the term "build" referred to the process of compiling and linking source code into executable code. Typically, these executable codes would be stand-alone applications, such as Microsoft Word or Adobe Photoshop. During the 1990s, the typical release cycle for applications (such as the Microsoft Windows operating system) was 12 to 24 months. [9]
In traditional software development at that time, developers would typically check in code once a day, and would run a "nightly build" after all the code was checked in. [10] If the code built successfully, they would run a series of unit tests and general functions tests, commonly referred to as "smoke tests." If any of the tests failed, the build was considered a failure and had to be fixed immediately. If the tests passed, then the build might be deployed to a test system for further testing. [11]
With the advent of multi-tier architectures, beginning with client-server and progressing to service-oriented architecture, a build became much more complex than simply compiling and linking code. Builds included many other types of activities, such as applying database changes, loading static content from a content management system, configuring software components, and deploying all or part of the build. [12] : 4
UrbanCode released the original Anthill OS as a free tool intended for build management. [13] : 397–401 [14] : 275–278 Due to the popularity of Anthill OS, UrbanCode created AnthillPro as a commercial product. [12] : 360 UrbanCode released the first commercial edition of AnthillPro in 2002. 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 addition to the growing complexity of the build/release cycle, the typical release cycle for software projects continues to shrink radically. [16] 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. According to agile software development, the main line of code should be ready to ship at any time; it may not be feature complete, but it must be of sufficient quality to be releasable. [12] : 49
AnthillPro supports such methodologies[ citation needed ] by monitoring the organization's various source control systems and triggering a build when a developer commits to a change. 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 for further testing and deployment. As additional tests are executed on the build, the team can gain greater confidence in the integration of the new code.
In 2006, UrbanCode released the third generation of AnthillPro. [17] This release was a complete rewrite that extended AnthillPro's capabilities beyond continuous integration into automated deployments. Unlike most CI servers, which were build-centric, this new version of AnthillPro used the build only as an initial test. After the build was complete, AnthillPro created binary artifacts that were then tested, deployed and promoted through a lifecycle on their way to production release. This version of AnthillPro included many new features, such as enriched reporting, release management, enhanced security, and the ability to execute workflow steps in remote machines.
AnthillPro can gather any reports generated by a build or test process and display them on the AnthillPro server's web interface for review by developers, testers or management. [18]
AnthillPro is designed to support the release management team's efforts. [19] AnthillPro provides an audit trail linking a build back to its source code and to every deployment and test executed against that build. The audit feature helps a release manager evaluate the readiness of a build to enter production. [20] AnthillPro encourages teams to use a similar automated process for production deployments, thus lowering the risk in a deployment. [21]
AnthillPro supports automated deployment of a build to a user-configured environment. [22] 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.
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 third-party tools straight out of the box. AnthillPro version 3.8, released in February 2012, integrates with over sixty[ citation needed ] third-party products, including J2EE servers, databases, build systems, infrastructure, and the Microsoft Platform. Additionally, AnthillPro supports external plugins that extend its automation framework to accommodate virtually any software that can be driven from the command line. [23]
The original Anthill was a simple continuous integration server released in 2001 and is still available today. In 2002, UrbanCode released the first commercial edition of AnthillPro. In 2006, UrbanCode released the third generation of AnthillPro, a complete rewrite which added support for distributed builds and control over the post-build lifecycle. [17]
AnthillPro version 3.6 (released in 2008) extended the tool-set to Application lifecycle management (ALM) [24] using centrally-managed automation for build, deploy, and test. This release added integration for numerous third party ALM point solutions, such as artifact repositories, SCM, issue-tracking, test-automation, change management systems and project management systems. [18] Other new features supporting this consolidation included detailed review of historical test results, flexible resource locking, and preflight builds. [25]
AnthillPro version 3.7 (released in 2009) increased AnthillPro's ability to integrate with other point tools in continuous integration, build automation, and ALM space. New features added integration plugins for seven of the most widely used source code analysis tools. This release introduced a new plug-in API that allows users to create their own custom integration plug-ins. [26] This release also introduced the AHP Tool, which allows users to create script actions from the command line and access data in the AnthillPro repository; and it introduced Agent User Impersonation, which gives administrators greater control over scripts run by agents. [23]
Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state.
Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:
Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well. These industrial style practices not only contribute to the growth of a company but also are key factors in enabling growth.
Application lifecycle management (ALM) is the product lifecycle management of computer programs. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management.
Build automation is the practice of building software systems in a relatively unattended fashion. The build is configured to run with minimized or no software developer interaction and without using a developer's personal computer. Build automation encompasses the act of configuring the build system as well the resulting system itself.
Azure DevOps Server, formerly known as Team Foundation Server (TFS) and Visual Studio Team System (VSTS), is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.
Aldon is a business unit of Rocket Software. It develops, manufactures, licenses and supports software change management products for the enterprise application lifecycle management (ALM) and software change management (SCM) markets.
Multi-stage continuous integration is a software development technique intended to achieve highly integrated parallel development activity while reducing the scope of integration problems.
Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; it includes testing and deploying software releases.
OpenText ALM (Application Lifecycle Management) is a comprehensive solution designed to support and enhance the entire lifecycle of application development and management. It provides robust tools for planning, development, testing, deployment, and maintenance, ensuring that software projects are delivered efficiently and effectively.
Open Services for Lifecycle Collaboration (OSLC) is an open community, originally proposed in 2008, to define a set of specifications that enable integration of software development. It has evolved, and continues to evolve, to areas such as Application Lifecycle Management (ALM), Product Lifecycle Management (PLM), IT Operations and more. The intention is to make life easier for tools users and tools vendors, by making it easier for tools to work together.
Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
Parasoft Virtualize is a service virtualization product that can create, deploy, and manage simulated test environments for software development and software testing purposes. These environments simulate the behavior of dependent resources that are unavailable, difficult to access, or difficult to configure for development or testing. It simulates the behavior of dependent resources such as mainframes, ERP systems, databases, web services, third-party information systems, or other systems that are out of direct developer/tester control. The product is used in conjunction with hardware/OS virtualization to provide developers and testers with the resources they need to execute their development and testing tasks earlier, faster, or more completely. Its technologies for automating continuous testing are used as part of continuous delivery, continuous integration, and continuous release.
Perforce Software, Inc. is an American developer of software used for developing and running applications, including version control software, web-based repository management, developer collaboration, application lifecycle management, web application servers, debugging tools, platform automation, and agile planning software.
In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment and production environment are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.
Wercker is a Docker-based continuous delivery platform that helps software developers build and deploy their applications and microservices. Using its command-line interface, developers can create Docker containers on their desktop, automate their build and deploy processes, testing them on their desktop, and then deploy them to various cloud platforms, ranging from Heroku to AWS and Rackspace. The command-line interface to Wercker has been open-sourced.
A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.
TestOps refers to the discipline of managing the operational aspects of testing within the software delivery lifecycle.