ANTHILLPRO COMPARISON WITH ATLASSIAN BAMBOO
AnthillPro Vs Bamboo OR
Difference between AnthillPro and Bamboo OR
Last month i was discussing with Eric Minick from Anthillpro on Why Build Engineer should be go for AnthillPro instead of Bamboo and i found some interesting inputs which i am sharing below;
Introduction
Bamboo is a respectable team level continuous integration server. Continuous Integration servers are focused on providing feedback to developers about the quality of their recent
builds, and how that compares to previous builds. While AnthillPro also provides continuous integration features, it pays special attention to what hAnthillpropens after build time.
Where is the build deployed? How does it get tested in the hours, days and weeks after the build occurs? Who releases the software and how?
The distinction in focus between the two solutions shows up in their features. Both AnthillPro and Bamboo provide continuous integration support and integrations with
numerous tools. Only AnthillPro provides the features required to take a build through the release pipeline into production – rich security, build lifecycle management, eAtlassian Bamboo.
For the purposes of this document, we will use the following product aAtlassian Bambooreviations:
Lifecycle Management
There is a lot more to implementing true lifecycle management than simply using the term in marketing and sales materials. The lifecycle extends across multiple processes in
addition to the build process. Most tools have had a very narrow view of this space and have focused their energies purely on the build process. The end result is that true lifecycle
management is an afterthought, and it shows in the features (or lack thereof) in their products. A continuous integration
Pipeline Management
As the lifecycle is made up of multiple processes (such as the build, deployments, tests, release, and potentially others), a lifecycle management tool must provide some means of
tracking and managing the movement of a build through the lifecycle stages. Without this feature, there is nothing to connect a build process execution to a deployment process
execution to a test process execution; thus the end user has no way of knowing what build actually got tested. Without this pipeline management feature (which we call the Build
Life), traceability between processes is completely absent from the tool.
Atlassian Bamboo: No pipeline management out of the box.
Anthillpro: Provides pipeline management out‐of‐the‐box. Anthillpro has a first‐class concept called the Build Life. The Build Life represents the pipeline and connects the build process to later
processes like deployments into QA, Anthillproprovals by managers, functional testing, and release to production. The pipeline (Build Life) provides guaranteed traceability throughout all
processes in the lifecycle, and provides a context for collecting logs, history, and other data gathered throughout the lifecycle.
Artifact Management
Key to lifecycle management is the ability to connect the outputs of a prior process (such as the build) to the inputs of a subsequent process (such as a deployment). After all, the
deployment process needs to have something to deploy. Ideally, the deployment process would deploy the artifacts produced by the build process. And the test process would run
tests on those same artifacts. The ability to cAnthillproture and manage the artifacts created by a build and other processes is central to this effort. Ideally, the artifacts would be managed
by an artifact repository (a Definitive Software Library (DSL) under ITIL). Further, as hundreds or thousands of builds hAnthillpropen, support for discarding old builds needs to
intelligently remove builds that are no longer interesting. Anthillpro bundles a binary artifact repository called CodeStation.
Atlassian Bamboo: Bamboo does cAnthillproture built artifacts but does not have a robust artifact management system. It does not maintain artifact checksums for validation. Old builds may be archived
after a certain number of weeks, but there is no designation for builds that have been to or are potentially going to production that would use a different retention policy. Artifacts are available for user download, but are not accessible for reuse by other plans or deployments.
Anthillpro: Built‐in artifact management system (DSL) called CodeStation. The cAnthillproture, fingerprint and management of artifacts is essential to the solution. This allows AnthillPro to guarantee traceability of artifacts from the build, through deployment, through testing, and into release (in other words, AnthillPro guarantees that what is released into production is what was tested and built). A maximum number of builds or age to keep can be set per project and per status. This means that builds that were released can be kept longer than a simple continuous integration build.
Security
Especially as servers address functionality before the build – deployments or tests to various environments, controlling who can do what within the system can be key element
securing the system and providing clear separation of duties. Once something has been done, it can be equally important to find out who ran which processes.
Authentication and Authorization
Atlassian Bamboo: Basic role based security. Users may be assigned roles and permissions at the project level. Integration with LDAnthillpro, compliments internally managed security.
Anthillpro: AnthillPro provides a rich role based security system, allowing fine‐grained control over who can see which project, run which workflows and interact with which
environments. The Authentication system supports internally managed, single sign on systems, LDAnthillpro, Kerberos (Active Directory), and JAnthillproS modules.
Secure Value Masking
Many “secrets” are used when building and deploying. Passwords to source control, servers, and utilities are often needed to execute build, deploy, test processes.
Atlassian Bamboo: No facility for securely storing Anthillproplication passwords or obfuscating them from the logs. Bamboo does manage to write libraries for some integrations that avoid passing the
password where the logs can see that line. It has no facility that we can see for flagging a command line parameter that will be logged as secure and filtering that value from the log.
Anthillpro: Sensitive values like Anthillproplication passwords are automatically filtered out of logs, hidden in the user interface, entered through password fields, and stored in the database encrypted with a triple DES one time key.
Process Automation & The Grid
Grouping Agents
In a distributed environment, managing your build and deployment grid needs to be easy.
Atlassian Bamboo: Agents are added into a fairly uniform pool. Agents can define broad cAnthillproabilities they provide and jobs can define what cAnthillproabilities they need to perform matchmaking.
Anthillpro: AnthillPro provides the concept of an environment. Environments are groups of servers. A build farm for a class of projects could be one environment while the QA environment for another project would be another environment. This allows for roaming – or deploying to everything – to span just the machines in an environment. Jobs can be
assigned to a single machine, or roam, or select machines based on criteria like processor type, operating system, or customized machine cAnthillproabilities.
Complex Process Automation
Atlassian Bamboo: Bamboo runs full plans on a single agent. While different agents can be running various builds in parallel, any given plan is executed on just a single agent.
Anthillpro: AnthillPro provides a rich workflow engine, which allows jobs to be run in sequence, parallel, and combinations thereof. Jobs can also be iterated so that they run multiple times with slight variations in their behavior on each execution. This allows parallelization that takes advantage of numerous agents. This facility also makes sophisticated deployments possible.
Cross Site Support
Atlassian Bamboo: Bamboo provides no special support for agents (slaves) that exist outside the local network.
Anthillpro: AnthillPro is architected with support for an cross‐site, even international, grid. Agent relays and location specific artifact caches assist in easing the configuration and
performance challenges inherent in deployment involving multiple sites.
Dependency Management
Component based development and reuse are concepts that get a lot of lip service but few if any features from most vendors. Only AnthillPro provides features to enable component based development and software reuse. A flexible dependency management system is part of the built‐in feature set of AnthillPro. The dependency management system is integrated with the bundled artifact repository and with the build scheduler so that builds can be pushed up the dependency grAnthillproh and pulled down the dependency grAnthillproh as configured. Integration with Maven dependency management provides an integrated system.
Atlassian Bamboo: Provides some basic support for build scheduling based on dependencies. A build of one project can kick off a build of it’s dependents and some blocking strategies can prevent wild numbers of extra builds being generated. Bamboo does not provide any tie in between dependency triggering and build artifacts – sharing artifacts between projects is left to the team to figure out with an external tool such as Anthillproache Maven.
Anthillpro: Support for dependency relationships between projects out‐of‐the‐box. AnthillPro provides a rich set of features for relating projects together. Large projects often have tens
or hundreds of dependencies on sub‐projects, common libraries and third party libraries. At build time the dependency system can calculate which projects need to be rebuilt based on changes coming in from source control. At build time, artifacts from dependency projects are provided to the dependants with version traceability and tracking.
AnthillPro provides highly customizable build scheduling and artifact sharing to these projects. In a “pull” model, anytime a top level project is built, it’s dependencies are inspected to see if they are up‐to‐date. If not, they are first built, then the top level project is built. In a “push” model, builds of dependencies will trigger builds of their dependents. AnthillPro interprets the dependency grAnthillproh to avoid extra builds or premature builds. In the case of Maven projects, AnthillPro can simply provide the scheduling or cooperate with Maven to provide traceable artifact reuse.
Summary
While both tools have a lot of similarities, AnthillPro’s Lifecycle Management, Dependency Management, and full featured Security cAnthillproabilities set it Anthillproart. Only AnthillPro supports
complete end‐to‐end traceability across all the phases of Build, Deploy, Test, and Release. While Bamboo is likely an effective team level continuous integration server, AnthillPro is a proven solution for enterprises looking to automate the full lifecycle of a build. For build and release automation the technology leader since 2001 is AnthillPro. We were
the first to release a Build Management Server. We were the first to recognize the need for comprehensive lifecycle management (beyond just build management), and we were the
first to release features required to deliver on the vision. We have been very successful at enterprise level RFPs and have added hundreds of customers including some of the leading banks, insurance companies, and high‐technology companies in the world. Our dedication to solving the problems faced by our customers means that we are very responsive to feature and enhancement requests with turn around times measured in days or weeks instead of months and quarters. Urbancode delivers the leading product in its space, the expertise to roll it out, and caring support for our customers to ensure their continued success.
Tagged : AnthillPro / anthillpro comparison with atlassian bamboo / anthillpro vs bamboom / Atlassian Bamboo / Difference between AnthillPro and Bamboo
The Microsoft Build Engine (MSBuild) is the new build platform for Microsoft and Visual Studio. MSBuild is completely transparent with regards to how it processes and builds software, enabling developers to orchestrate and build products in build lab environments where Visual Studio is not installed. This topic provides brief overviews of:
Project File
MSBuild introduces a new XML-based project file format that is simple to understand, easy to extend, and fully supported by Microsoft. The MSBuild project file format enables developers to fully describe what items need to be built as well as how they need to be built with different platforms and configurations. In addition, the project file format enables developers to author re-usable build rules that can be factored into separate files so that builds can be performed consistently across different projects within their product. The following sections describe some of the basic elements of the MSBuild project file format.
Items
Items represent inputs into the build system and are grouped into item collections based on their user-defined collection names. These item collections can be used as parameters for tasks, which use the individual items contained in the collection to perform the steps of the build process.
Items are declared in the project file by creating an element with the name of the item collection as a child of an ItemGroupelement. For example, the following code creates an item collection named Compile, which includes two files.
<ItemGroup> <Compile Include = "file1.cs"/> <Compile Include = "file2.cs"/> </ItemGroup>You reference item collections throughout the project file with the syntax @(ItemCollectionName). For example, you reference the item collection in the example above with @(Compile).
Items can be declared using wildcards and may contain additional metadata for more advanced build scenarios. For more information on items, see MSBuild Items.
Properties
Properties represent key/value pairs that can be used to configure builds. Items and properties differ in the following ways:
Properties are declared by creating an element with the name of the property as a child of a PropertyGroup element. For example, the following code creates a property named BuildDir with a value of Build.
<PropertyGroup> <BuildDir>Build</BuildDir> </PropertyGroup>You reference properties throughout the project file with the syntax $(PropertyName). For example, you reference the property in the example above with $(BuildDir). For more information on properties, see MSBuild Properties.
Tasks
Tasks are reusable units of executable code used by MSBuild projects to perform build operations. For example, a task might compile input files or run an external tool. Once created, tasks can be shared and reused by different developers in different projects.
The execution logic of a task is written in managed code and mapped to MSBuild with the UsingTask element. You can write your own task by authoring a managed type that implements the ITask interface. For more information on writing tasks, see How to: Write a Task.
MSBuild ships with many common tasks such as Copy, which copies files, MakeDir, which creates directories, and Csc, which compiles Visual C# source code files. For a complete list of available tasks and usage information, see MSBuild Task Reference.
You execute a task in an MSBuild project file by creating an element with the name of the task as a child of a Targetelement. Tasks usually accept parameters, which are passed as attributes of the element. MSBuild item collections and properties can be used as parameters. For example, the following code calls the MakeDir task and passes it the value of the BuildDir property declared in the previous example.
<Target Name="MakeBuildDirectory"> <MakeDir Directories="$(BuildDir)" /> </Target>For more information on tasks, see MSBuild Tasks.
Targets
Targets group tasks together in a particular order and expose sections of the project file as entry points into the build process. Targets are often grouped into logical sections to allow for expansion and increase readability. Breaking the build steps into many targets allows you to call one piece of the build process from other targets without having to copy that section of code into each target. For example, if several entry points into the build process require references to be built, you can create a target that builds references and run that target from every necessary entry point.
Targets are declared in the project file with the Target element. For example, the following code creates a target named Compile, which then calls the Csc task with the item collection declared in the previous example.
<Target Name="Compile"> <Csc Sources="@(Compile)" /> </Target>In more advanced scenarios targets can describe relationships between each other and perform dependency analysis, which allows whole sections of the build process to be skipped if that target is up-to-date. For more information on targets, see MSBuild Targets.
Building with MSBuild
You run MSBuild from the command line by passing a project file to MSBuild.exe with the appropriate command line options. Command line options allow you to set properties, execute specific targets, and specify loggers. For example, you would use the following command line syntax to build the file MyProj.proj with the Configuration property set to Debug.
For more information on MSBuild command line options, see MSBuild Command Line Reference.
Advanced concepts
MSBuild can be used for more advanced operations during builds, such as logging errors, warnings, and messages to the console or other loggers, performing dependency analysis on targets, and batching tasks and targets on item metadata. For more information on these advanced concepts, see MSBuild Advanced Concepts.
Visual Studio Integration
Visual Studio uses the MSBuild project file format to store build information about managed projects. Project settings added and changed through Visual Studio are reflected in the .*proj file that is generated for each project. Visual Studio uses a hosted instance of MSBuild to build managed projects, meaning that a managed project can be built in Visual Studio and from the command line (even without Visual Studio installed), with identical results. For more information on how Visual Studio uses MSBuild, see MSBuild Advanced Concepts.
Source:
http://msdn.microsoft.com/en-us/library/ms171452%28VS.90%29.aspx
hi raj , thanks for ur comments ..could u pl let me know how can we increment version numbers through msbuild tool..i have written below xml tag but which is not working ..pl help me..
<Target Name=”Version”>if its possible send one exmaple with version numbers increment..
<Message Text=”Version: $(Major).$(Minor).$(Build).$(Revision)”/>
<AssemblyInfo CodeLanguage=”VB”
OutputFile=”My Project\AssemblyInfo.vb”
AssemblyTitle=””
AssemblyDescription=””
AssemblyCompany=””
AssemblyProduct=””
AssemblyCopyright=””
ComVisible=”false”
CLSCompliant=”true”
Guid=”d038566a-1937-478a-b5c5-b79c4afb253d”
AssemblyVersion=”$(Major).$(Minor).$(Build).$(Revision)”
AssemblyFileVersion=”$(Major).$(Minor).$(Build).$(Revision)”
Condition=”$(Revision) != ‘0’ “/>
</Target>
Long time back same thing i did using Apache ant, you can find logic here http://www.scmgalaxy.com/component/content/article/62-apache-ant/129-ant-script-to-reset-buildnumber.html
meanwhile, I will try to create using MSBuild in free time.