There are various ways using you can release the artifacts.  There are two plugins which is being frequently used is…

1. Maven Release Plugin
2. Maven Git Flow Plugin

Maven Release Plugin
This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform.

Maven Git Flow Plugin
The Maven JGit-Flow Plugin is based on and is a replacement for the maven-release-plugin enabling support for git-flow style releases via maven.

Reference
http://george-stathis.com/2013/11/09/painless-maven-project-releases-with-maven-gitflow-plugin/
http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
http://stackoverflow.com/questions/4466714/how-to-customise-the-tag-format-of-the-maven-release-plugin
https://bitbucket.org/atlassian/jgit-flow/wiki/Home
http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html#Overriding_the_default_tag_name_format
http://www.fiveminutes.eu/maven-release-plugin-8-tips-tricks/
https://bitbucket.org/atlassian/jgit-flow/wiki/Home.wiki#!getting-the-plugin
http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/

The post Release Artificats with Maven Release and Git Flow Plugins appeared first on scmGalaxy.

Advance Features of Smart Build Tools

{slideshare}[slideshare id=6995921&doc=advancefeaturesofsmartbuildandtoolsstudy-110220215438-phpapp02&type=d]{/slideshare}

The post What are the Advance Features of Smart Build Tools? appeared first on scmGalaxy.

The tasks can be scheduled to run on the same machine (Master), or on a different machine (Slave). A master is a installation of Hudson, that can manage one or more slaves. The role of master remains same in Master slave setup. It serves HTTP requests, and it can still build projects on it’s own.

Slaves are computers that are setup to build projects triggered from the master. A separate program called slave agent runs on slave computer. In this article we’ll discuss about how to setup Hudson to executed distributed builds using Master slave. One computer can be configured to execute multiple slave agents.

How it works

When the slaves are registered to a master, the master starts distributing loads to slaves. The delegation depends on the specific job. The job can be configured to either execute on the master, or it can be tied to a specific slave. On the other hand, the jobs can be configured to freely roam between slaves, wherein the job is executed using the free slave. As per the user is concerned, the setup is transparent. The results for all jobs are viewable using the Master, irrespective of the Slave that executed the job.

The slave may be built using any Operating system. The Master slave setup is highly helpful while the user has to execute the job on different Operating system. Consider this use case: The application is expected to run on different operating system, Linux, Solaris and Windows system. To address this need, the user can install Hudson on any machine, say Linux, and add 2 slaves: Solaris and Windows. The user can add 3 different jobs, one running on Master itself and others running on slave machines.

Methods to set up Slave agents

The slave can be launched from Master using any of below methods:

1. Launch Slave agents on Unix machines via SSH.
2. Launch Slave agents via JNLP.
3. Launch Slave agents via execution of command on the master.
4. Let Hudson control windows slave as a windows service.

The following screenshot illustrates the list of modes under which the Hudson slave can be launched.

Set up Slave agents on Unix machines via SSH

Hudson has a built-in SSH client implementation that it can use to talk to remote sshd and start a slave agent. This is the most convenient and preferred method for Unix slaves, which normally has sshd out-of-the-box. Click Manage Hudson, then Manage Nodes, then click New Node. In this set up, the connection information is supplied, including SSH host name, user name and authentication credentials. The authentication is performed using password or ssh keys. If it is configured to use ssh keys, the SSH public key should be copied to ~/.ssh/authorized_keys file. Hudson will do the rest of the work by itself, including copying the binary needed for a slave agent, and starting/stopping slaves.

 

Depending on the project and hardware resource availability, the user Desktop can be used as one of Slave, without affecting his day-to-day activities, thus avoiding the need for dedicated Slaves.

Establish slave agent via Java Web Start

Another way of launching slave is to start a slave agent through Java Web Start (JNLP). In this approach, the user will login to the slave node, open a browser and open the slave page using the URL pointed to the Master. It may look like the following URL:

http://masterserver:port/hudson/jnlpJars/slave.jar

The user is presented with the JNLP launch icon. If user click the icon, the Java Web Start kicks in and it launches a slave agent on this computer.

This mode is convenient when the master cannot initiate a connection to slaves, such as when it runs outside a firewall while the rest of the slaves are in the firewall. The disadvantage is, if the machine with a slave agent goes down, the master has no way of re-launching it on its own.

Set up slave agent headlessly

This launch mode uses a mechanism very similar to Java Web Start, except that it runs without using GUI, making it convenient for an execution as a daemon on Unix. To do this, the user should configure this slave to be a JNLP slave by downloading slave.jar, and then from the slave, run a command like this:

java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp

The slave.jar file is downloaded from the above mentioned URL. Make sure to replace slave-name with the name of the slave setup in Master.

By default, Hudson runs on port 8080. It can be installed and managed without the need for super user privilege. The super user privilege is not required to manage both Master and Slave.

The below diagram illustrates the list of configuration parameters specific to a slave.

 

set up Slave Agent using own scripts

If the above modes is not flexible, the user can write his own script to launch the Slave agent. The script is placed in the Master computer and Hudson runs this script whenever it should connect to the slave. The script may use the remote login program like SSH, RSH to establish connection between Master and slave.

The script would execute the slave agent program like java -jar slave.jar. The stdin and stdout for the script should be connected to the master. For example, the script that does ssh myslave java -jar ~/bin/slave.jar would satisfy this need, when it is executed from the Master web interface. For this reason, running this script manually from the command line does no good.

The copy of slave.jar can be downloaded from the above mentioned URL. Launching the slave agent using this mode requires additional setup in the Slave. The benefit is that when the connection goes bad, the user can use Hudson web interface to re-establish the connection.

The post How to Setup Configure Hudson Master Slave? – Complete Guide appeared first on scmGalaxy.

What is POM
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this are the build directory, which is target; the source directory, which is src/main/java; the test source directory, which is src/main/test; and so on.
The POM was renamed from project.xml in Maven 1 to pom.xml in Maven 2. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.
Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.

Super POM
The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects. The snippet below is the Super POM for Maven 2.0.x.
The snippet below is the Super POM for Maven 2.0.x.
4.0.0
Maven Default Project

central
Maven Repository Switchboard
default
http://repo1.maven.org/maven2

false

central
Maven Plugin Repository
http://repo1.maven.org/maven2
default

false

never

target
target/classes
${artifactId}-${version}
target/test-classes
src/main/java
src/main/scripts
src/test/java

src/main/resources

src/test/resources

target/site
release-profile

performRelease

true
org.apache.maven.plugins
maven-source-plugin

attach-sources

jar

true
org.apache.maven.plugins
maven-javadoc-plugin

attach-javadocs

jar

true
org.apache.maven.plugins
maven-deploy-plugin

true

Minimal POM
The minimum requirement for a POM are the following:

• project root
• modelVersion – should be set to 4.0.0
• groupId – the id of the project’s group.
• artifactId – the id of the artifact (project)
• version – the version of the artifact under the specified group

Here’s an example:

  4.0.0

  com.mycompany.app

  my-app

  1

A POM requires that its groupId, artifactId, and version be configured. These three values form the project’s fully qualified artifact name. This is in the form of ::. As for the example above, its fully qualified artifact name is “com.mycompany.app:my-app:1”.
Every Maven project has a packaging type. If it is not specified in the POM, then the default value “jar” would be used.
Project inheritance
Elements in the POM that are merged are the following:

• dependencies
• developers and contributors
• plugin lists (including reports)
• plugin executions with matching ids
• plugin configuration
• resources

The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.

The post Project Object Model – What is POM? appeared first on scmGalaxy.

Table of Contents
Agile Development Challenges
Deployment Challenges
Build Acceleration Challenges
Integration with Elastic and Cloud Computing
Workflow Management
Reference:

Agile Development Challenges

Two of the core principles of agile development are: “deliver working code frequently” and “working software is the primary measure of progress.” More and more teams, from ISVs to enterprise IT groups, are recognizing the quality and productivity benefits of integrating early and often. Whether you want to just build and test more frequently or implement a comprehensive agile process, you’ll need to ensure that your build and test process is:

• fast
• automated (not requiring manual intervention)
• reliable (broken builds are the enemy of an agile approach)

Addressing the build-test-deploy process is one of the best first steps toward an agile development model.

Agile Development  Challenge			Impact
Builds require manual intervention			Integrating often will overwhelm a manual build process
Slow build cycle (whether long individual builds or a large number of build targets)			Long builds limit the number of iterations possible in a day Builds longer than ~30 minutes rule out Continuous Integration
Developers introducing errors during integration or production builds			If developers can’t do preflight builds and tests on all targets/platforms prior to check-in, Continuous Integration can turn into Continuously Broken Builds

Deployment Challenges

Deployment of a real world application is a complex, and all-too-often, a manual process. The complexity comes from the fact that the application may need to be deployed to any number of environments: Development (DEV), Quality Assurance (QA), User Acceptance Testing (UAT), Pre-production (STAGE), and Production (PROD). Each of these environments is typically slightly different requiring different accounts, password, and setting and thus it may seem like manual intervention is required.
Complicating matters is the fact that today’s business applications comprise multiple moving parts that all need to be synchronized and deployed together. For example, a typical J2EE application can be made up of an EAR file, database changes, some static content, and environment changes (such as JDBC connection pools, Message Queues, etc.). Making sure that all these pieces get deployed on the correct machines and in the correct order can feel like a daunting task, especially if you need to repeat it for each environment. Keep in mind that each environment may have a different number of database servers, application server, HTTP server, etc.

Build Acceleration Challenges

Slow software build cycles are more than just an annoyance. Whether you have long monolithic builds or a large number of smaller builds that take a long time, they are having a real impact on your development organization.

• Wasted time, frustration waiting for builds
• Fixing broken builds delays testing
• Fewer bugs fixed, fewer features added
• Developers avoid builds
• QA may skip tests to meet deadlines

A recent survey of more than 350 development professionals found that 68% reported broken builds at least a few times per month (and often weekly), and fixing those typically wasted 2 weeks per year. The majority said their builds were each more than 1 hour long, with 24% reporting builds of 2-4 hours, which translates to time not spent creating great software.

Integration with Elastic and Cloud Computing

In a large infrastructure with many projects, the CI server often experiences variable task loads with unpredictable load peaks (such as during releases). In an environment with fixed resources, this leads to build queue growths, increased build times, and poor build scheduling control.
Computing clouds such as Amazon EC2 provide a nice and efficient way to scale resources to fulfill variable demands with random load spikes. Such rapid demand growths is exactly what happens in Build Server during CI “rush hours,” when everyone starts personal builds before going home, and also during pre-release days, when every new fix needs another round of unit tests, and build feedback time becomes mission-critical.
Build Server utilizes EC2 via virtual build agents. Virtual build agents are similar to standard ones, except that they run on virtual instances on the Amazon EC2. This means that Build Server is able to dynamically start as many instances of such agents as needed, in order to keep the build queue under control under high loads. Additionally, Build Server can shut down virtual build agents when they are not needed anymore, to minimize EC2 instances uptime.
While being a great solution for mitigating peak loads and maintaining constant build feedback time, Amazon EC2 integration also provides great cost optimization opportunities, as each resource accumulates costs only while in use.

Workflow Management

In recent years, build management solutions have provided even more relief when it comes to automating the build process. Both commercial and open source solutions are available to perform more automated build and workflow processing. Some solutions focus on automating the pre and post steps around the calling of the build scripts, while others go beyond the pre and post build script processing and drive down into streamlining the actual compile and linker calls without much manual scripting.

Tools Comparison

Reference:

http://www.electric-cloud.com
www.anthillpro.com
http://www.atlassian.com
www.jetbrains.com/teamcity
http://www.openmakesoftware.com

The post Advance Features of Smart Build Tools appeared first on scmGalaxy.