Advantages of Git over SVN and perforce

What are the advantage of GIT over Subversion and perforce?

Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.

Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.

Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.

A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.

While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.

Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.

In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.

Git features

Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.

Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.

Easy branching: Branches and tags are much easier to create and switch in Git.

Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.

Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.

Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.

Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.

Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.

SVN features

GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.

Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.

Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.

Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.

The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.

Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.

Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.

On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery, X.org, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.

Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.

Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.

The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.

Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.

Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.

Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.

If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”

Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.

True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 Kernel.org surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.

One more good link for Advantahe of git over SVN(Subversion) …

http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

Tagged : / / / / / / / / /

A Comparison of Nagios, Zenoss and Zabbix

Source – OpenSource

Feature Nagios Zenoss Zabbix
Basic features (CPU, disk, memory) YES YES YES
Auto discovery Partial YES Partial
License Free Free Free
Inventory Support No Free Free
Plug in support Free Free Free
Web Dashboard Good Excellent Excellent
Windows Monitering Partial YES YES
SNMP Trapping Partial YES YES
Syslog Monitering Partial YES YES
Trend Analysis Partial YES Partial
Google Maps View NO NO YES
Graphical Reports NO YES YES
User friendly configuration YES Partial Partial
Performance and reliability Medium High Low
Plug-in API support Partial YES YES
Security Monitering NO NO NO
Tagged : / / / / / /

Difference between Maven 1 and Maven 2

What is Maven 2?
Maven 2.0 is a complete rewrite of the ‘original’ Maven application (‘Maven 1’). As such, it is very different from Maven 1, and not backwards-compatible (eg, it cannot execute Maven 1 plugins). However, Maven 2.0 is the latest stable release of the Maven application, and new users are generally encouraged to use it for all new projects.
If you are familiar with Maven 1, you can find some information about moving to Maven 2 here or on the main Maven site.
Maven 1
To access the repository from your project, add the following line to your project.properties or build.properties.
maven.repo.remote=http://download.java.net/maven/1/,http://www.ibiblio.org/maven/
Maven 2
For Maven2, one needs to add the following into a project’s pom.xml, or into conf/settings.xml <settings>/<profiles>/<repositories> (NOT in mirrors/mirror) where Maven2 is installed:

<repository>
<id>java.net</id>
<url>http://download.java.net/maven/1</url>;
<layout>legacy</layout>
</repository>

Maven 2 Lifecycles

Lifecycles are groupings of goals that define a process for building a project. Goals are bound to lifecycles to define a sequence that must be accomplished to produce results. Lifecycles ensure that users building projects with Maven only need to learn a small set of commands. Whereas Maven defines a default set of goals for each typical lifecycle, developers can bind additional goals to lifecycles to transparently add functionality to a build.
Typical lifecycles include:

  • compile—compile the source code
  • test—unit test the compiled source.

Note: Unit tests should not require the classes to be packaged or deployed.

  • package—bundle the compile and tested source code into a distributable package, such as a jar or war.
  • integration-test—employ the package as necessary and run integration tests.
  • install—install the package into the local repository. This allows the package to be utilized as a dependency of other projects.
  • deploy—copies the final package into the remote repositories for sharing and use with other projects.

As you can see, each lifecycle depends upon and builds upon the next. As a result, when a goal is bound to the compile lifecycle, all lifecycles will ensure its execution.
Lifecycles can be executed in conjunction with standalone goals. For instance, commonly the clean:clean goal is executed before the install goal. This is done by invoking:

m2 clean:clean install

Native Multiproject Support

One of the best practices that Maven strongly encourages is the idea that a single project should result in a single artifact, or package, being created. This best practice results in simplified builds and organized project structures. By natively supporting a hierarchical structure of projects, Maven now makes developing enterprise projects which implement this approach easier.
Maven 1 included a plugin for working with related of projects—or multiprojects. Maven 2 takes multiproject builds a step further by including a specialized parent descriptor and native multiproject execution support. As a result, any goals or lifecycles invoked upon a multiproject POM will result in each subproject goal being achieved.

Other Enhancements

Several other changes are included in Maven 2. Maven has been rewritten to be smaller and faster. The architectural changes make embedding Maven into other tools easier and allows for faster command line execution. Maven 2 depends upon fewer dependencies, resulting in a smaller distribution.
The way extensions are made to Maven has been changed in Maven 2. Instead, developers are encouraged to utilize JavaBeans for enhancements. Whereas scripting is allowed (through marmalade support—which includes a jelly facade), it is no longer the tool of choice. All extensions are made through the development of plugins (projects can no longer be customized through scripting in the maven.xml).
The introduction of a settings.xml file replaces the need for properties files. The settings file can be defined at a system, user, or project level. Settings are used to define private configuration information, including usernames and passwords. Project properties (including plugin configuration) are now all defined in the pom.xml.

Understanding Maven 2 Project Types

The first step to creating a maven project is determining which project template, or archetype, your Maven project should be configured as. Archetypes define which type of artifact will be produced by a project. Several archetype templates exist. The standard archetype will produce a standard library jar file. Templates also exist for webapps/wars, Maven plugin projects, documentation Web sites, and more.

Creating Project Descriptors

The archetype:create goal can be utilized to create a basic pom.xml for you project. This basic POM will allow you to execute all of the lifecycles and goals associated with any maven project. The archetype:create goal should be executed as follows:

m2 archetype:create -DgroupdId=com.daviddewolf.maven -DartifactId=example

This simple command creates the basic infrastructure needed for a project. It creates the pom.xml as well as the basic directory structure of for both source and test code. The following structure indicates the directories and files produced by issuing the archetype:goal command as listed above.

+ root
  - pom.xml
  + src
    + main
      + java
        + com
          + daviddewolf
            + maven
              + example
                - App.java
    + test
      + java
        + com
          + daviddewolf
            + maven
              + example
                - TestApp.java

This simple structure that is created is enough to get started with Maven. All of the lifecycles now can be utilized. A simple invocation of the install lifecycle will compile, test, and package the application and then deploy it to the local system repository for use by other projects.
Once created, the POM can be customized to meet the requirements of the specific project. Documentation on the Maven POM can be found on the Maven2 Web site.

Goals You Should Know About

The introduction of lifecycles in Maven 2 has greatly reduced the number of goals that a developer must be aware of. Still, the following goals will undoubtedly be found useful (and can be utilized as soon as the basic descriptor has been generated).

  • clean:clean Clean all artifacts and intermediary files created by Maven
  • idea:idea Generate project files for the IntelliJ IDEA IDE
  • eclipse:eclipse Generate project files for the Eclipse IDE
  • javadoc:javadoc Generate the javadocs for the project
  • antrun:run Run a specified ant target
  • clover:clover Generate a coverage report for the project
  • checkstyle:checkstyle Generate a checkstyle report for the project
  • site:site Generate a documentation Web site for the project. This site will include many information reports concerning the project.

For more information concerning these and other goals, see the Maven2 Web site.
Conclusions
Learning Maven is not difficult; it simply requires a willingness to accept a new philosophy for building applications. Maven utilizes a a centralized project descriptor to intelligently build applications with prebuilt build tools. This differs greatly from ant and other build tools in that project developers are no longer required to write build systems by using a comprehensive set of utilities. This change will save development teams significant time and has started a revolution in build tools.
It is important to remember that Maven2 is still currently only released as Beta Software. Although it is mature enough to utilize in most projects, all of the Maven 1 plugins have not yet been migrated to Maven 2. With time, Maven 2 will become more widely accepted and the number of available plugins will grow beyond what is even available in Maven 1.
Reference:
http://www.developer.com/open/print.php/10930_3552026_2
http://www.sonatype.com/books/maven-book/reference/installation-sect-upgrade-detail.html

Tagged : / / / / /

Sonar Vs Squale

Based on feedback of Fabricefrom Squale, Please find a difference between Sonar and Squale

In a nutshell, we could say that Sonar is good at gathering code metrics and displaying them in various visualisations, mainly targeting technical people, while Squale is good at aggregating those metrics into high level factors to address top-level managers.

In facts, Squale and Sonar both: Similarties
– analyse code for different languages
– get metrics from code and store them into a database
– display them so that it is possible to drill down the code and analyse where complexity and risks are

In term of differences:
– Sonar relies on Maven while Squale has not this requirement
– Sonar does not offer advanced quality models to aggregate raw quality data into high level factors
– Squale does not display code in its web interface (we think this is not a major feature as you can only read code but bot modify it: the most important is to have the feedback in the IDE)
– it is a bit more complex to extend Squale, while Sonar has a good extension mechanism

Tagged : / / / / /

ANTHILLPRO COMPARISON WITH ATLASSIAN BAMBOO

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 : / / / /

Compare between RSM and Sonar

Metrics Tools
Category Metric Comment RSM Sonar
Function Metrics LOC Lines of Code Per Function, All Functions Yes Yes
eLOC (Effective LOC) Per Function, All Functions Yes Yes
lLOC (Logical Statements LOC) Per Function, All Functions Yes No
FP Function Points Derived from LOC metrics Per Function, All Functions Yes No
Comments Lines Per Function, All Functions Yes Yes
Blank Lines Per Function, All Functions Yes Yes
Physical Lines Per Function, All Functions Yes Yes
Number of Input Parameters Per Function, Yes No
Number of Return Points Per Function, Yes No
Interface Complexity (Parameters + Returns) Per Function, Yes Yes
Cyclomatic Complexity Logical Branching Per Function, All Functions Yes No
Functional Complexity (Interface + Cyclomatic) Per Function, All Functions Yes No
Functional Quality Analysis Per Function, Yes Yes
Number of functions Total, Average, Maximum and Minimums All Functions Yes Yes
Logical Lines All Functions Yes No
Return Points All Functions Yes No
Function Parameters All Functions Yes No
Total Quality Profile All Functions Yes ?
Class Metrics Number of public, private, protected data attributes Per Class, All Classes Yes Yes
Number of public, private, protected methods Per Class, All Classes Yes Yes
Template Type Per Class, Yes No
Inheritance Per Class, Yes No
Depth of Inheritance Tree Per Class, Yes Yes
Number of derived child classes per base class Per Class, Yes Yes
LOC Lines of Code Per Class, All Classes Yes Yes
eLOC (Effective LOC) Per Class, All Classes Yes No
lLOC (Logical Statements LOC) Per Class, All Classes Yes No
Comments Lines Per Class, All Classes Yes Yes
Blank Lines Per Class, All Classes Yes Yes
Physical Lines Per Class, All Classes Yes Yes
Number of Input Parameters Per Class, All Classes Yes No
Number of Return Points Per Class, All Classes Yes No
Interface Complexity (Parameters + Returns) Per Class, All Classes Yes No
Cyclomatic Complexity Logical Branching Per Class, All Classes Yes No
Class Complexity (Interface + Cyclomatic) Per Class, All Classes Yes Yes
Class Quality Analysis RSM Quality Analysis Per Class, Yes No
Total number of classes All Classes Yes Yes
Inheritance Tree All Classes Yes No
Number of Base Classes All Classes Yes Yes
Number of Derived Classes All Classes Yes Yes
Derived/Base Class Ratio All Classes Yes No
Maximum and Average Inheritance Depth All Classes Yes No
Maximum and Average Number of Child Classes All Classes Yes No
Total Quality Profile All Classes Yes ?
Namespace or Package Metrics Number of classes Per Namespace, All Namespace/Packages Yes Yes
Number of functions Per Namespace, All Namespace/Packages Yes Yes
Average functions per class Per Namespace, Yes Yes
Number of public, private, protected data attributes Per Namespace, All Namespace/Packages Yes Yes
Number of public, private, protected methods Per Namespace, All Namespace/Packages Yes Yes
LOC Lines of Code Per Namespace, All Namespace/Packages Yes Yes
eLOC (Effective LOC) Per Namespace, All Namespace/Packages Yes No
lLOC (Logical Statements LOC) Per Namespace, All Namespace/Packages Yes No
Comments Lines Per Namespace, All Namespace/Packages Yes Yes
Blank Lines Per Namespace, All Namespace/Packages Yes Yes
Physical Lines Per Namespace, All Namespace/Packages Yes Yes
Number of Input Parameters Per Namespace, All Namespace/Packages Yes No
Number of Return Points Per Namespace, All Namespace/Packages Yes No
Interface Complexity (Parameters + Returns) Per Namespace, All Namespace/Packages Yes No
Cyclomatic Complexity Logical Branching Per Namespace, All Namespace/Packages Yes No
Package/Namespace Complexity (Interface + Cyclomatic) Per Namespace, All Namespace/Packages Yes No
Quality Analysis RSM Quality Analysis Per Namespace, Yes No
Total Quality Profile All Namespace/Packages Yes ?
File Metrics LOC Lines of Code Yes Yes
eLOC (Effective LOC) Yes No
lLOC (Logical Statements LOC) Yes No
FP Function Points Derived from LOC Yes No
Comments Lines Yes Yes
Blank Lines Yes Yes
Logical and Physical Lines Yes Yes
Comment and White space percentages Yes Yes
Average Character line length Yes No
Memory Allocation and De-allocation metric Yes No
Language Keyword use Yes No
Language Construct use Yes No
Extract Comments per file for understandability rating and spell checking Yes No
Extract Strings per file for spell checking Yes No
Create files in line numbered format for code reviews Yes No
Number of Quality Notices per file Yes No
Metrics differentials between two file version Yes No
Project Metrics Total LOC, eLOC, lLOC, Comment, Blanks, Lines Yes Yes
FP Function Points Derived from LOC metrics Yes No
Total Function Metrics Yes No
Total Class Metrics Yes Yes
Total Namespace Metrics Yes No
Inheritance Tree and Metrics Yes No
Language Keywords, constructs and metrics Yes No
Quality Profile Yes ?
Metric Estimation Factors for software estimates Yes No
Total Language Metrics Example Yes No
Total C, C++ and Header Files Yes No
Total Java Files Yes No
Total Number of Files Yes Yes
Baseline Metric Differential Yes Yes
Tagged : / / / / /

Maven Vs Ant | Maven or Ant which is better ?

maven-vs-ant

Maven Vs Ant

Tagged : / / / / / / / / / / /

Comparison Between UCC, CLOC, POWERSOFTWARE,EZ-Metrics and Metrixware

ucc-vs-cloc-vs-powersoftware-vs-ez-metrics-vs-metrixware

Unified CodeCount (UCC) CLOC POWERSOFTWARE EZ-Metrics Metrixware
Languages
C/C++, C#, Java, SQL, Ada, Perl, ASP, ASP.NET, JSP, CSS, HTML, JavaScript, VB, and VbScript YES – All ADA, Assembly, ASP, C#, C/C++, CSS, Fortran, IDL, HTML, Java, JavaScript, JSP, Perl, PHP, PL/SQL, PowerBuilder, Python, Ruby, ShellScript, Textfiles, VB6 / VB.NET / VBScript, VHDL, Windows Batch and XML YES ALL
Platforms
Windows & Linux Linux 2.6.9, Unix, Mac OS X, Windows 9x/Me/XP/Vista, Solaris BOTH Windows, Linux planned but no date Both
Baselines comparison
How the tool manages folder hierarchy changes? The tool tries to match files between two baselines using filenames. As such, two files having the same name in different folder structures can be matched. The tool also detects to match and compare files if the folder is changed while filenames of the files contained in the folder are kept the same. NA No information NA
How the tool manages files which are renamed? Currently, the tool does not handle files renamed. However, if the file is renamed but its content does not change, the tool considers it as a duplicate. NA No information NA
How the tool manages files or block swapping? We have not handled swapping blocks of code yet. If the code is copied from one place to another, it is considered as deleted and added. If files are swapped and its filename does not change, the tool can match and compare them. Available No information Available
What is the algorithm used for line change detection? For comparing between lines, we detect the number of common characters between them and determine whether they are modified or deleted using a threshold. This threshold can be specified through a parameter named –t. For detecting bulk of changed or added code, we implemented our own algorithm for detecting longest common sequences. I am sorry, it is quite complex to be described in this email. We are documenting it in detail, and if you are interested I can send you a copy after it is completed. SLOC, PERL Mod No information NA
Miscellaneous
GUI & CLI CLI CLI Both but separate products GUI
CSV & XML Output Only TXT XML HTML, CSV, RAW XML data YES
Provide Qualitative metrics? No. The tool is focused on software size metrics. NO yes but separate product YES
Price Open Source Open Source KEPM (which includes EPM) costs 1,995 USD for a single license or 4,995 for a 5-user license Commericial
Frequency of the releases No information in net Regular One minor/Major release per month or 2 months.
Date of last release December,2009 Apr-10 16-Mar-10
Press on the net Not many reviews available in net Nope
Integration with quality platform Provides different language source for the integration. Nope
Recommend NO Yes No No
Algorithm confidence The total sizing of analyzed source code files in terms the SLOC count contains the highest degree of confidence. However, the sizing information pertaining to the sub classifications (compiler directives, data lines, executable lines) has a somewhat lower level of confidence associated with them.

Misclassifications of the sub classifications of SLOC may occur due to:

(1) user modifications to the UCC tool,
(2) syntax and semantic enhancements to the parsed programming language,
(3) exotic usage of the parsed programming language, and
(4) integrity of the host platform execution environment.

SLOC algorithm with perl string handling features and SPAN mdoules NA
Advantages / Drawbacks / Comments Output not according to our need.
Limited Output Format
Delta is not useful
Low Processing speed
Output according to our need.
Output in many form(CSV, XML, TXT and Mysql)
Delta is useful according to our needs
Fast processing
I tried 30 days trial version. They given web based account/dashboard to add src file and generate output. Which was not functional and could not test it functionality in details. Basic functionality is not working.
Tagged : / / / / / / / / / / / / / / / /

SLOC Tools Comparison | SLOC Tools Differences | SLOC Tools Comparison Table

sloc-tools-comparison

Tool Open Source – Commercial URL
CAST Commercial www.castsoftware.com
Sonar Open Source www.sonarsource.org
SLOC Open Source -> Commercial http://www.dwheeler.com/sloccount/
RSM Commercial www.msquaredtechnologies.com
LocMetrics Commercial www.locmetrics.com
EZ-Metrics Commercial http://www.jamesheiresconsulting.com/Products.htm
Metrixware Commercial www.metrixware.com
Parasoft (Jtest) Commercial www.parasoft.com/
Squale Open Source www.squale.org/
KODERS Commercial www.koders.com
PRACTILINE www.practiline.com
POWERSOFTWARE Commercial http://www.powersoftware.com/
CLOC Open Source http://cloc.sourceforge.net/
Unified CodeCount (UCC) Open Source http://sunset.usc.edu/research/CODECOUNT/
Tagged : / / / / / / / / / / / / / / /

Anthillpro Comparison with Atlassian Bamboo – Continuous Integration Tools Review

anthillpro-vs-atlassian-bamboo

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 : / / / / / / / / / / / / / / / / / / / / /