What are the functions of a Build tool ?

• Generate documentation from source code
• Compile source code
• Create jar/war/tzg package of compiled code, properties files and dependent JARs
• Sync the package to the repository

is it possible to open multiple PuTTY sessions in a same window ?

use Multi tab PuTTY

• It can open multiple tabs of PuTTY to work on multiple platform in same window
• allows to save login / password apart from hostname so you do not have them manually
• You will get all the saved session on Home page and side menu.

Download link

http://ttyplus.com/multi-tabbed-putty/

What are the usage of PuTTY tool ?

Functions provided by PuTTY

• Save hosts and preferences for reuse
• Command-line SCP and SFTP clients, called "pscp" and "psftp" respectively.
• Port forwarding with SSH (Local / remote / dynamic port forwarding)
• IPv6 support
• Public-key authentication support (no certificate support)
• Supports 3DES, AES, Arcfour, Blowfish, DES
• Support for local serial port connections
• No installation required

Ant vs. Maven vs. Gradle

Ant

+ Simple to learn
+ Popular

- No convention ; Need to define the project layout (structure)
- XML becomes complicated and unmanageable for long term project

Use Ant when :

• No need of dependency management
• Quick development of project
• Legacy project unfit for Maven convention

Maven

+ Dependency management

• Just declare dependencies, Maven will download them over the network (Like, Ant+Ivy)
• Also manage Dependencies of the dependencies (Transitive dependencies)

+ Has convention to write configuration ; No need to provide project structure
+ has a Life cycle

- Dependencies cannot handle well conflicts between different versions of same library
- Difficult to write complex scripts and customized tasks

Use Maven when : 

• Product development, to manage multiple versions and branches 
• Several teams working on dependent modules

Gradle

+ combines good parts of both tools
+ Life cycle like Maven
   Compile, Static analysis, Testing, Packaging and deployment
+ Doesn't use XML
+ Short and clear script

Git vs. SVN

DISTRIBUTED vs. CENTRALIZED

• Git is distributed
• SVN is centralized versioning system.

AVAILABILITY

• If you cannot reach SVN server, you cannot commit the code.
• In Git, local copy on your system is the repository and you can commit to it - Local Source Control

COMPLEXITY

• Git is complex to use : 
• "git clone" provides checkout of repository code
• "git checkout" switches the branch
• "git commit" commits teh code locally
• SVN is much simpler to learn

FAST

• Git is faster than SVN

USAGE
Git is preferred :  

• When developers do not commit to master repository too often.
• need better support for merging and branching.
• for Open source projects
• Fork the project for yourself
• Commit the changes to your Fork
• Ask the project owner to pull your changes

What are Version control systems ?

Version control system

• Also known as a Revision Control System 
• It is a repository of files.
• Every change made to the files is tracked, along with who made the change, when they made, why they made it and references to problems fixed, or enhancements introduced, by the change.
• Changes are usually identified by an incrementing number or letter code also known as revision number or revision.
• These systems are essential for any form of distributed, collaborative development.

Benefits

• Collaboration : A team of developers (which could be distributed geographically) may be working on the same set of files at once without interrupting each other's work. 
• Change management : The changes can be inspected, reviewed or rolled back as needed. For example, If you need the xyz.java as it was on May 17, 2008 - no problem ! 
• Tracking ownership : Every change is associated with the name of the person, so we know whom to give kudos to or ask questions. 
• Tracking evolution : Every change is associated with a short description, so you just need to pull a change log of some class to see how it evolved and who did what. 
• Branching : It is possible to create a copy (branch) of the entire project for some specific purpose (i.e.: prototyping or developing a fix for the important customer) without disrupting development workflow. 
• Continuous integration : Ability to split evolution of a software project into incremental changes allows to run all sorts of checks and tests against each incremental change in a continuous manner.

Version Tracking

Developers may wish to compare today’s version of some software with yesterday’s version or last year’s version.

Knowing the what, who, and when of changes will help with comparing the performance of particular versions, working out when bugs were introduced (or fixed), and so on.

Any problems that arose from a change can then be followed up by an examination of who made the change and the reasons they gave for making the change.

Coordinating Teams

Version control is central to coordinating teams of contributors.

It lets one contributor work on a copy of the resources and then release their changes back to the common core when ready. Other contributors work on their own copies of the same resources at the same time, unaffected by each other’s changes until they choose to merge or commit their changes back to the project.

Any conflicts that arise - when two contributors independently change the same part of a resource - are automatically flagged when the changes are merged.

Common terms

• Repository : database server that contains all files and their history.
• Working copy : local version of files on somebody's machine. It may contain local unversioned changes.
• Trunk : home folder for some project within the repository. It usually contains all the latest changes.
• History (or ChangeLog) : a list of changes that were done to a file or folder since it was created.
• Latest (or Head) : latest available version of some file or folder.
• Revision : another word that means current version of file or folder.

Common operations

• Check out : first operation required to work with any repository. It involves creating working copy that mirrors some folder on the server (usually that's trunk).
• Commit (or Check In) : sending your local changes back to the server, so that other people can get them as well.
• Update : updating local working copy to have all the lasted changes that were committed to the server since the last time you've checked it.
• Revert : discard all your local changes to the working copy.
• Diff (or Change, Delta) : differences between two versions of the same file; or an operation involving actually looking up what was changed between two versions.
• Create patch : automatically create a file that describes all the changes that were done to the working copy (basically containing all diffs). Then these changes could be reviewed by somebody else and committed to the repository.

Advanced operations

• Conflict : It happens when somebody else changed the file, while you were working on it locally.
• Resolve : to fix contradicting changes by reviewing and manually merging them (VCSs can automatically resolve majority of the conflicts).
• Tag : to place a human readable label on some revision (i.e.: when releasing a product); or a noun representing such a label.
• Branch : to start a separate line of development over some old revision (i.e.: when fixing bugs for the previously released version).
• Merge : bringing together changes from different sources (i.e.: when applying a bug fix from some branch to a trunk).

Centralized vs. Distributed Version control systems

Centralized Version control systems

These are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system.

Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole.

For example: A change to a JSP file and the corresponding .java file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most common Centralized Version control systems are CVS, Subversion (or SVN) and Perforce.

A Typical Centralized Version Control Workflow

 1. Pull down any changes other people have made from the central server.

 2. Make your changes, and make sure they work properly.

 3. Commit your changes to the central server, so other programmers can see them.

Distributed Version control systems (DVCS)

These systems do not necessarily rely on a central server to store all the versions of a project’s files.

Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

In practice, it’s not a problem. Most programming projects consist mostly of plain text files (and maybe a few images), and disk space is so cheap that storing many copies of a file doesn’t create a noticable dent in a hard drive’s free space.

Modern systems also compress the files to use even less space.

One common misconception about distributed version control systems is that there cannot be a central project repository.

3 most popular of these are Mercurial, Git and Bazaar.

Advantages Over Centralized Version Control

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems :

• Performing actions other than pushing(moving changes to repository) and pulling (getting new changes) changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
• Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
• Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
• Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

Disadvantages Compared to Centralized Version Control

There are almost no disadvantages to using a distributed version control system over a centralized one. Distributed systems do not prevent you from having a single “central” repository, they just provide more options on top of that.

There are only two major inherent disadvantages to using a distributed system : 

• If your project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly.
• If your project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.

Install and setup SonarQube on Windows ?

A. Setup database for SonarQube

1. Install MySQL

2. Setup MySQL using below commands or script

# Create SonarQube database and user.

# Command: mysql -u root -p < create-sonar-db.sql
CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci;

CREATE USER 'sonar' IDENTIFIED BY 'sonar';
GRANT ALL ON sonar.* TO 'sonar'@'%' IDENTIFIED BY 'sonar';
GRANT ALL ON sonar.* TO 'sonar'@'localhost' IDENTIFIED BY 'sonar';
FLUSH PRIVILEGES;

Ensure that MySQL instance is running and able to connect database “sonar” through the SQL client.

All the tables would be created automatically after the sonar ant task would run.

B. Install and configure SonarQube

Install SonarQube

http://www.sonarqube.org/downloads/  

Configure SonarQube server

Set Sonar configuration (sonarqube/conf/sonar.properties) : 

a. Update JDBC properties 

sonar.jdbc.url=jdbc:mysql://<host>:3306/sonar

sonar.jdbc.username=root 

sonar.jdbc.password=root 

sonar.jdbc.driverClassName=com.mysql.jdbc.Driver

b. Update Sonar server properties sonar.host.url=http://<host>:8090 

sonar.web.host=<yourhost> 

sonar.web.port=8090 

sonar.web.context=/

c. Start the Sonar server 

Go to  sonarqube-4.0\bin and select your operating system (Eg: windows-x86-64 for window 7) and start Sonar server.  

Example (Windows)

cd C:\E_Drive_Backup\jenkins_backfile\sonarqube-4.0\bin\windows-x86-64 

Run the StartSonar.bat file. 

Example (Linux)

/home/sonarqube-4.0/bin/linux-x86-64/sonar.sh start | stop | status

d. Check sonar logs 

tail -f /home/sonarqube-4.0/logs/sonar.log

e. Check the sonar process 

Sample

root   51589 51587 18 12:06 ?        00:01:08 /opt/jdksun64/1.7.0_11/bin/java -Djava.awt.headless=true -XX:MaxPermSize=128m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -Djruby.management.enabled=false -Xms256m -Xmx512m -Djava.library.path=./lib -classpath ../../lib/sonar-application-4.0.jar:../../lib/tomcat-embed-core-7.0.42.jar:../../lib/tomcat-embed-jasper-7.0.42.jar:../../lib/logback-classic-1.0.13.jar:../../lib/tomcat-embed-logging-juli-7.0.42.jar:../../lib/slf4j-api-1.7.5.jar:../../lib/wrapper-3.2.3.jar:../../lib/logback-core-1.0.13.jar:../../lib/jul-to-slf4j-1.7.5.jar:../../lib/commons-io-2.4.jar:../../lib/logback-access-1.0.13.jar:../../conf:../../extensions/jdbc-driver/h2/h2-1.3.172.jar:../../extensions/jdbc-driver/mysql/mysql-connector-java-5.1.26.jar:../../extensions/jdbc-driver/postgresql/postgresql-9.1-901-1.jdbc4.jar:../../extensions/jdbc-driver/mssql/jtds-1.2.7.jar -Dwrapper.key=XvBBAc9aNgEiKSZJ -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=51587 -Dwrapper.version=3.2.3 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp org.sonar.application.StartServer

C. Sonar Scanner installation 

1. Download Sonar scanner from :    http://docs.sonarqube.org/display/SONAR/Analyzing+with+SonarQube+Scanner 
   Extract the downloaded file into any directory <install_directory>

2. Update the global settings (Server URL) by editing <install_directory>/conf/sonar-runner.properties : 
  #----- Default SonarQube server
  #sonar.host.url=http://localhost:9000
3. Set environment variables    a. SONAR_RUNNER_HOME set to <install_directory>
    b. Add the <install_directory>/bin directory to PATH

4. Check the installation in a new shell / window
Linux
sonar-runner -h
sonar-runner -h -Dsonar.verbose=true
Windows
sonar-runner.bat -h
sonar-runner.bat -h -Dsonar.verbose=true
 

D. Sonar Scanner configuration and launch
 

1. Set Sonar runner properties
Add Mysql and Sonar web server configuration in sonar-scanner/conf/sonar-runner.properties
Example
# Configure here general information about the environment, such as SonarQube DB details for example
# No information about specific project should appear here
#----- Default SonarQube serversonar.host.url=http://10.239.199.191:8090/
#----- Default source code encoding
#sonar.sourceEncoding=UTF-8
#----- Global database settings (not used for SonarQube 5.2+)sonar.jdbc.username=sonar
sonar.jdbc.password=sonar

#----- PostgreSQL
#sonar.jdbc.url=jdbc:postgresql://localhost/sonar
#----- MySQLsonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&amp;characterEncoding=utf8

 

2. Change PROJECT_HOME in sonar-runner.batset PROJECT_HOME=%SONAR_RUNNER_HOME%\Projects

3. Make "Projects" folder in %SONAR_RUNNER_HOME% directory
 

4. Create a configuration file "sonar-project.properties" in the root directory of the project: 
Example
# must be unique in a given SonarQube instance
sonar.projectKey=MyTool
# Name displayed in the SonarQube UI
sonar.projectName=MyTool Analysis

sonar.projectVersion=1.0
 

# Path is relative to the sonar-project.properties file.

# Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional if sonar.modules is set.
# If not set, SonarQube starts looking for source code from the directory containing 
# the sonar-project.properties file.
sonar.sources=.
# For Example 
# sonar.sources=C:/workspace/G3R6C1/admin/src/main/java 
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8
# Language JAVAsonar.language=java

5. Launch Sonar runner from project base directory
sonar-runner

Note : Scanner does directory indexing and Indexing is only done from where “sonar-runner” command is executed.

 

Check SonarQube Dashboard

Check sonarqube dashboard on sonarqube server UI.

There will be “MyTool Analysis” report.
Double click on that link and view and analyze the code quality of project.
 

Example

Open source Version Control Systems

Centralized version control : Only one master copy of the software is used. 

Example : SVN, CVS

Distributed version control : There isn’t one centralized code base to pull the code from. Different branches hold different parts of the code.

Example : Git, Mercurial, Bazaar, Monotone, Fossil

CVS

• Very simple system for making sure files and revisions are kept up to date
• Earlier technology
• Still quite useful for backup and sharing files
• Tortoise CVS is a great client for CVS on Windows
• Many IDEs has plugins for CVS like : Xcode (Mac), eclipse, NetBeans and Emacs

SVN

• Widely used
• Most open-source projects use Subversion as a repository (SourceForge, Apache, Python, Ruby etc.)
• Many clients available : Tortoise SVN for Windows, Versions for mac, Xcode for Apple etc.

Git

• New rising version control systems
• Fast and efficient system
• Fast branching and merging operations 
• Not as easy to pick up as CVS or SVN, so it’s much harder to use for a beginner
• Initially developed by Linux kernel creator Linus Torvalds
• Every Git clone a complete repository and mirror of the original repository
• Clone contains the complete history of changes and full revision tracking facilities, and is not tied to a central server
• Many major open source projects uses or migrated to Git to power their repositories
  Example : Linux Kernel, WINE, Fedora, Rails, php etc.
• TortoiseGit is a GUI for using the Git SCM on Windows.
• Github powered the usage of git by providing beautiful front end.

Mercurial

• Extremely fast , high performance and scalable 
• used to handle large distributed projects
• Much simpler system than Git 
• Less functions to learn and similar to those in other version systems
• Also comes with a standalone web UI and extensive documentation
• TortoiseHg provides a GUI and explorer for Mercurial SCM

Bazaar

• offers a very friendly user experience
• supports many different types of workflows : solo / centralized / decentralized
• Easy to modify and setup
• allows users to commit their own branches of source code for particular application

LibreSource

• Web portal used to manage collaborative projects. 
• based on Java/J2EE and is more a set of visual collaborative tools to help facilitate projects and teams
• Collaboration hub for project development. 
• has built-in features such as Wiki pages, forums, trackers, Synchronizers, Subversion repositories, files, download areas, drop boxes, forms, instant messaging and more 
• provides tools which do not have a big learning curve

Monotone

• Monotone places higher value on integrity than performance. 
• Simply downloading the initial repository can take time due to the extensive validation and authentication required. 
• Fairly easy to learn if you’re familiar with other CVS systems
• It can import previous CVS projects
• Not quite as popular as other CVS

Fossil

• offers version control, bug tracker and technotes
• uses HTTP, HTTPS, or SSH
• Repository and its contents are stored in SQLite database
• Built in web interface in a stand-alone executable

SouceJammer

• 100% written in Java
• Source control and versioning system
• consists of 2 components :
• Server side : maintains files and version history, handles check-in/out etc.
• Client side : manages files at client-side and makes requests to server