What is the difference between git stash and git commit?

git stash -- The command saves your local modifications away and reverts the working directory to match the HEAD commit. It allows you to store your uncommited modifications into a buffer area called stash, and deletes it from the branch you are working on. You may later retreive them by applying the stash.

git commit -- This records your change for next push and this event is recorded in history too.

What is the difference between rebase and merge in Git?

By merging you create a new commit with the result of the fusion of the target branch and source branch.

With rebase you put the commit of the current branch on top of the source branch.


Usage rules:
* use rebase on your own branch before asking for a merge in order to have a clean history
* use merge when you work with other people on the same branch


In case of doubt use merge it's safer.

What is the difference between the reset and revert commands in the Git version control system?

Git revert command is used to revert a particular commit.
Most of the times a commit is reverted when it is causing the regression during testing.

When git revert is done this itself results in a commit(author as a person who is reverting). 

Usage is as follows:
git revert [options] <commit-ish>
or: git revert <subcommand>
    --quit                end revert or cherry-pick sequence
    --continue            resume revert or cherry-pick sequence
    --abort               cancel revert or cherry-pick sequence
     -n, --no-commit       don't automatically commit
    -e, --edit            edit the commit message
    -s, --signoff         add Signed-off-by:
    -m, --mainline <n>    parent number
    --rerere-autoupdate   update the index with reused conflict resolution if           possible
    --strategy <strategy>      merge strategy
    -X, --strategy-option <option> option for merge strategy

In simple terms to revert a particular commit git revert <commit-id>.
This internally creates a separate commit for reverting a previous commit.

Gir reset on the other hand is primarily used to  reset the current HEAD to the specified state.

git reset is also very helpful in the following scenarios

1. When you have made some changes and you no longer wanted them to be committed you just wanted to go back to the older clean state
git reset --hard HEAD
2. When you wanted to go to two commits back
git reset --hard HEAD~2
3. When you are doing git pull. It might result in merging errors. In this case you might just want to get rid of the mess, then you can simply use 
git reset --hard HEAD
4. You might have added a file to commit using  git add abc.c
but later you realized you do not want to add then you can use the following
git reset -- abc.c

What is the use of git cherry-pick command?

cherry-pick command will be useful, when you want to pick specific commit from one branch and apply it on another branch.

Let's say two developers working on a feature, each developer working on separate task relate to the feature on two different branches and commit it once the task has been done. At the end of the day, they need to merge both the task together and merge it with master branch. In this case, we pick one of the developer commit by copy it's commit ID got from git log command and navigate it to another developer branch and using the following command git cherry-pick <copied-commit-id>apply the changes in the commit to the current developer branch.

How to Run LoadRunner in Jenkins Continuous Integration

To start using the HP Application Automation tools with LoadRunner you need to do the following setup work in Jenkins:

 

First install the Jenkins HP Application Automation tools add-in

1) In your Jenkins instance, navigate to the Manage Jenkins area and click on the Manage Plugins link.

2) Click on the Available Tab.

3) Under the Filter textbox, enter HP.

4) Under the Available tab, look for the name HP Application Automation Tools.

5) Click on the Install checkbox and click on the Download Now and Install After

Restart button.

Configure Jenkins

Once the add-in is installed and you have restarted Jenkins:

1. Click on the Jenkins>New Job menu option. 
   
2. Enter a Job Name – I named my RunLoadrunner – and click on the Build a free-style software project option. Click OK
3. Under the your new project’s configuration scroll down to the Build section and click on the Add build step and click on the Execute HP tests from file system option
4. Under Build you should now have an option for LoadRunner-Specific Settings.. – Click on it.
5. Under the LoadRunner Settings enter the following:
   

• Controller Polling Interval – the time to poll the LR Controller for your scenario status
• Scenario Execution Timeout – this is the total time for the execution of all your scenarios
• Errors to Ignore – – during the run you can tell which errors to ignore

1. Under the Build/TestsSECTION enter the path to your LoadRunner scenario. For example my scenario named JnekinsDebug.lrs lives under my D:\myLoadRuner directory. So my Tests field = D:\myLoadRunner
2. Under the Post-build Actions section click on the Add post-build action and select Publish HP tests result
3. Apply and Save your settings
4. Run the LR job you just created like you would any standard Jenkins job

Set LoadRunner Scenario SLA

One thing toWATCH out for is to make sure that your scenario has a SLA defined. If it does not your Jenkins job will fail with a message similar to this:

To fix just go into your Scenario in the LoadRunner Controller and add a SLA:

LR Jenkins CI Wrap-up

That is how you integrate LoadRunner with Jenkins. Hope it helps. Let me know if I missed anything.

How to trigger builds on SVN commit

What plugins and plugin features do I need to set in order to get my Jenkins job to trigger a build anytime code is committed to a SVN project? I have installed both the standard SVN plugin as well as the SVN tagging plugin but do not see any new features that allow trigger configuration.

NOTE:

Please post your answers in Comments box

Jenkins CI configuration: Build/test/deploy scenarios

My goal: set up a Jenkins-server capable of pulling down our github repos and run through the build-deploy-test scenarios.

So I have set up a Jenkins-server. But I don't understand how I have to run through the build-deploy-test scenarios of my project.

My project contains 1 repository which I putted into a job. I have installed the Build Pipeline Plugin. Will this be enough? It's difficult for me to understand the set-up. How do I have to start?

NOTE:

Please post your answers in Comments Box

DevOps - CI and CD Pipe line

Demo Project on CD Pipe line 

1) Continuous Integration:

1. Make Sure your code is in compile state -- Green

2. Execute unit tests - 100% -> written by developers

3. Reporting build status & test reports

2) Continuous Delivery:

4. Deployment

5. Running AutomationSUITS

6. Reporting with 100% tests cases success

Servers:

Deployment Server:           -- Tomcat / WebLogic

CI/Build Server:                 -- Jenkins Master

Example Application Activities:

Part 1. Commit the source code and Build Script in SVN

Part 2. Commit the DB and other deployment scripts in SVN

Part 3. Automate every thing through Jenkins in Step by Step

Part 4. Trigger the jobs for every commit/push 

Part 5. Perform a build and deployment Steps

Steps:

Part 1. Commit the source code and Build Script in SVN

Sub Version (SVN) :

-- Let's start the subversion and Access the URL:- IP:80/repo

-- Url can be verified from httpd.conf file

-- Push the code:  Let's checkout the code to client machine from of current repo

-- Copy the source code of the app and Build Scripts to the R1 release directory

        -- svn co http://IP:80/repo/branches/R1 -- username 

-- cd R1

-- svn up

-- svn info

-- svn ls

-- svn add *

--svn commit -m "Source code has been added"

Part 2. Commit the DB and other deployment scripts in SVN

Commit the DB and other deployment scripts in SVN:  Let's checkout the code to client machine from of current repo.

Part 3. Automate every thing through Jenkins in Step by Step

Jenkins:

       -- Start Jenkins Server and Access the URL

       -- Create a slave by configuring working directory.

       -- Creating a job

                -- Specify the Label Expression of 'Salve Machine Node'

-- Source code ManagementSECTION

-- copy the URL 'Repository URL'

              -- Build Section

-- Invoke Ant version as 'Default'

-- Targets 'war'

-- In case Error:Select the 'EXecute Shell'

-- rm -rf dist

--EXPORT ANT_HOME

-- export JAVA_HOME

-- APACHE_HOME/bin/ant war

-- Post Build Actions 

-- Archive the Artifacts

-- Files to archive '**/*.war'

-- Apply and Save it.

Note: If it is required JDK,Ant in slave machine, add the required JAVA_HOME,ANT_HOME variable at Node --> Environment variableSECTION and tools section.

Note: Make sure the build is successful

Part 4. Trigger the jobs for every commit/push 

Specify when and how your build should be triggered. The following example polls the SVN repository every 15 min and triggers a build, if something has changed in the repo.

Part 5. Perform a build and deployment Steps

-- Manual Deployment:

-- Go to Deployment Server

-- App Server (Tomcat)

-- DB (MySql)

-- JDK (1.7)

-- Deployment Steps:

-- 1. Identify the artifacts 

-- .war file and DB Scripts

-- 2. Find out the server and check pre requisites

-- 3. Stop the services

  -- 4. Take the backup of existing deployment

-- 5. Deploy it

-- DB deployment

-- App/Service Deployment

-- 6. Start the Service

-- 7. Verify

DevOps - CI and CD Operations on AWS (Part - II)

AWS Services for DevOps

This walk through shows you how to use the following AWS services:

• AWS CodeCommit, a fully managed source control service that makes it easy for you to host secure and highly scalable private Git repositories. 

• AWS CodeDeploy, which automates code deployments to any instance, including Amazon ElasticCOMPUTE Cloud (Amazon EC2) instances and on-premises servers. 

• AWS CodePipeline, a continuous delivery service for fast and reliable application updates.

Understanding the Walk through:

In this walk through, you will:

1.  Use AWS CloudFormation to give users access to the required AWS services and the corresponding AWS resources and actions.

2. Create a source code repository in AWS CodeCommit and then use AWS CloudFormation to launch an Amazon EC2 instance that connects to the repository.

3.    Download the source code you will deploy and then push it into the repository.

4.  Use AWS CloudFormation to create the deployment target (an Amazon EC2 instance) and related AWS resources that are compatible with AWS CodeDeploy.

5.  Use AWS CloudFormation to create and run a pipeline in AWS CodePipeline to automate continuous delivery of the repository's source code to the deployment target.

6.  Verify the deployment's results on the deployment target.

7.  Make a change to the source code and then push it into the repository, triggering an automatic redeployment to the deployment target.

8.  Verify the deployed change on the deployment target.

9.  Use AWS CloudFormation to clean up the resources you created for this walkthrough.

Step 1: Set Up to Access Participating Services

In this step, you will set up user access to AWS services used in this walk through. Specifically, you will:

1.    Create an AWS account and, optionally, an administrative IAM user in the account.

2.    Use the root account or an administrative user in the account to create an IAM group and IAM user.

3.    Attach AWS service access permissions to the new group.

4.    Add the new user to the new group.

5.    Sign in to the AWS Management Console with the new user's credentials.

Step 1.1: Create an AWS Account

In this step, you will create an AWS account that you will use to complete the tasks in step 1.2. If you already have an account you want to use, sign in to the AWS Management Console with the account's root credentials.

To create an AWS account

1.    Open http://aws.amazon.com.

2.    Choose Sign In to the Console.

3.    Complete the instructions to create an AWS account.

4.   After your account has been created, sign in to the AWS Management Console with  the account's root credentials.

5.    Go to Step 1.2: Create IAM Resources.

Step 1.2: Create IAM Resources

In this step, you will complete the following tasks:

• Create an IAM group and an IAM user specifically for use with this walkthrough.
• Attach participating AWS service access permissions to the new group.
• Add the new user to the new group.
• Sign in to the AWS Management Console with the new user's credentials.

The following procedure uses an AWS CloudFormation template to complete this step's tasks more quickly.

To create the IAM resources

1. Open the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation/.
2. In the AWS region selector, choose US East (N. Virginia). 
3. Choose Create Stack.
4. On the Select Template page, for Specify an Amazon S3 template URL, type the URL to the AWS CloudFormation template for this step: https://s3.amazonaws.com/aws-for-devops/cfn-templates/IAMSetup.template. Choose Next.
5. On the Specify Details page, for Stack name, type a stack name (for example, DevOpsIAMSetup). If you choose a different name, substitute it for DevOpsIAMSetup throughout this walkthrough.
6. The settings in the Parameters are used to:
• Create an IAM group and an IAM user and then add the new user to the new group.
• Attach to the new group a default set of access permissions for AWS CloudFormation, AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline.

To accept these default settings, for NewUserPassword, type a password for the new user, and then skip to step 7 of this procedure.

The followingTABLE shows which settings to choose in the Parameters area.

I want to create an IAM group and IAM user in my AWS account specifically for use with this walkthrough.	Leave CreateGroupAndUser set to the default value of Yes. For NewUserPassword, type a password for the new user to use to sign in to the AWS Management Console. (The user will be asked to change this password after initial sign-in.) Note If you have an existing group (or user) you want to use for this walkthrough, set CreateGroupAndUser to No.
I want to use an existing IAM group in my account for this walkthrough, and I already have at least one IAM user added to the group.	Set ExistingGroup to Yes. For GroupName, type the name of the group.
I want to use an existing IAM user in my account for this walkthrough.	Set ExistingUser to Yes. For UserName, type the name of the user.
I want to attach AWS CloudFormation administrative access permissions to the IAM groups (or users).	Leave CloudFormation set to the default value of Yes. Note Set CloudFormation to No only if the existing group (or user) you want to use for this walkthrough already has AWS CloudFormation administrative access permissions attached.
I want to attach AWS CodeCommit full access permissions to the IAM groups (or users) I specified earlier.	Leave CodeCommit set to the default value of Yes. Note Set CodeCommit to No only if the existing group (or user) you want to use for this walkthrough already has AWS CodeCommit full access permissions attached. For more information
I want to attach AWS CodeDeploy default access permissions to the IAM groups (or users).	Leave CodeDeploy set to the default value of Yes. Note Set CodeDeploy to No only if the existing group (or user) you want to use for this walkthrough already has AWS CodeDeploy default access permissions attached, or if you do not want to deploy to AWS CodeDeploy deployment targets. For more information, see Step 1: Provision an IAM User in the AWS CodeDeploy User Guide.
I want to attach AWS CodePipeline full access permissions to the IAM groups (or users).	Leave CodePipeline set to the default value of Yes. Note Set CodePipeline to No only if the existing group (or user) you want to use for this walkthrough already has AWS CodePipeline full access permissions attached. For more information

Note

This walkthrough attaches very permissive access permissions to groups (or users). In production scenarios, as an AWS security best practice, you should limit these access permissions to only the AWS service actions and resources you need.

7. Choose Next.
8. On the Options page, choose Next. (You do not need to change anything on this page.)
9. On the Review page, select I acknowledge that this template might cause AWS CloudFormation to create IAM resources, and then choose Create.

Note

The steps in this walk through that instruct you to create AWS Cloud Formation templates are very similar. If you forget how to create a template, use this topic as a refresher.

10. In the list of stacks, wait until CREATE_COMPLETE is displayed under Status for DevOpsIAMSetup.

If you created a group and user, you can get information about them by choosing the corresponding Physical ID links on the Resources tab for the stack.

11. Sign out of the console, and then sign back in to the console with the new or existing user's credentials.

Step 2: Set Up for AWS CodeCommit

In this step, you will set up access to AWS CodeCommit. Specifically, you will:

• Create a repository in AWS CodeCommit to store the source code to deploy.
• Launch an Amazon EC2 instance running Amazon Linux to connect to the AWS CodeCommit repository.
• Create an Amazon EC2 key pair, which you will use to log in to the newly launched instance.
• Confirm that you have successfully cloned the repository onto the instance.

Steps:

• Step 2.1: Create a Repository
• Step 2.2: Create a Key Pair
• Step 2.3: Launch an Instance
• Step 2.4: Explore the Cloned Repository

Step 2.1: Create an AWS CodeCommit Repository

In this step, you will create an AWS CodeCommit repository that will store the source code.

To create the AWS CodeCommit repository

1.Open the AWS CodeCommit console at  https://console.aws.amazon.com/codecommit/.

2. In the AWS region selector, choose US East (N. Virginia). 

3. On the Dashboard page, choose Create new repository.

4. On the Create new repository page, for Repository name, type a repository name (for example, MyDemoRepo), and then choose Create repository. If you use a different name, substitute it for MyDemoRepo throughout this walkthrough.

5. On the Dashboard page, choose MyDemoRepo.

6. On the Code: MyDemoRepo page, choose Clone URL, and then choose HTTPS. Make a note of the URL that is displayed. You will need it for Step 2.3: Launch an Instance.

Step 2.2: Create an Amazon EC2 Key Pair

In this step, you will create an Amazon EC2 key pair that you will use to sign in to the instance that you will launch in Step 2.3: Launch an Instance.

If you already have a key pair, make sure it was created in the US East (N. Virginia) region, and then go to Step 2.3: Launch an Instance.

To create an Amazon EC2 key pair

1.  Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

2.  In the AWS region selector, choose US East (N. Virginia).

3.  Choose Key Pairs.

4.  Choose Create Key Pair.

5.  In the Create Key Pair dialogBOX, for Key pair name, type the name of your new key pair, and then choose Create.

6.   When prompted, save the resulting .pem file to your local workstation.

7.   Go to Step 2.3: Launch an Instance.

Step 2.3: Launch an Amazon EC2 Instance to Access the AWS CodeCommit Repository

This instance allows users to log in to it by using the SSH protocol. The instance has permission to take any AWS CodeCommit action for any AWS CodeCommit repository across the AWS account. AWS CloudFormation runs commands on the instance to set up the Git credential helper for AWS CodeCommit, clone the repository's contents onto the instance, and establish the user name and email address for all commits to the repository. 

To launch an Amazon Linux instance set up with AWS CodeCommit

1.  Use the AWS CloudFormation console to create a stack in the US East (N. Virginia) region based on the following Amazon S3 template URL: https://s3.amazonaws.com/aws-for-devops/cfn-templates/CodeCommitInstance.template

On the Specify Details page, for Type, type the Amazon EC2 instance type to launch (for example, t2.micro).

For KeyPair, type the name of the key pair that you will use to log in to the instance 

For Tag, type a tag for the instance to help you more easily identify it in places such as the Amazon EC2 console (for example, CodeCommitInstance).

For LocalRepo, type the name of the subdirectory to create in the /home/ec2-user directory on the instance and then clone the repository into (for example, my-demo-repo). If you choose a different name, substitute it for my-demo-repo throughout this walkthrough.

For UserName, type the user name you want to associate with all commits to the repository.

For UserEmail, type the email address you want to associate with all commits to the repository.

2.  When CREATE_COMPLETE is displayed for Status for the stack, you can explore the resources created by the stack. Otherwise, go to Step 2.4: Explore the Cloned Repository.

To explore the Amazon EC2 resources created by the stack

1.    In the AWS CloudFormation console, choose the Resources tab for the stack.

2.  To view details about the newly launched instance, for CodeCommitInstance, choose the Physical ID link.

3.    To view details about the newly created security group, on the Description tab in the Amazon EC2 console for the instance, choose the Security groups link.

To explore the IAM resources created by the stack

1. In the AWS CloudFormation console, choose the Resources tab for the stack.

2.To view the newly created IAM instance profile, for CodeCommitInstanceProfileRole, choose the Physical ID link.

Step 2.4: Explore the Cloned AWS CodeCommit Repository

In this step, you will log in to the newly launched instance and confirm that you successfully cloned the repository onto it.

To explore the cloned AWS CodeCommit repository on the Amazon Linux instance

1. Launch an Instance. For CodeCommitInstance, choose thePhysical ID link. Then, in the Amazon EC2 console for the instance, find the Public DNS value.
2. From the instance's command prompt, run the cd /home/ec2-user/rnsRepocommand or the cd ~/rnsRepo command (or simply cd rnsRepo because on login the command prompt defaults to the /home/ec2-user directory).
3. From the rnsRepo directory, run the ls -a command. This lists the directory's contents, which should include the following:

. .. .git

4. From the rnsRepo directory, you can run the ls .git command, which will produce the following output. These are Git-specific folders and files for the repository that should not be edited directly:

branches  config  descripton  HEAD  hooks  info  objects  refs

There is not much more to explore yet, because you have not yet pushed any source code into it. You will do that in the next step.

DevOps - CI and CD Operations on AWS (Part - I)

CI and CD on AWS

What Is DevOps?

DevOps is a combination of cultural philosophies, practices, andTOOLS that increases an organization's ability to deliver applications and services at high velocity, evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market. Good DevOps practicesencourage software development engineers and operations professionals to work better together. This results in closer collaboration and communication, leading to shorter time-to-market, better code quality and maintenance, and more reliable releases. 

Why does DevOps matter?

• High-­performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster.

• Lean management and continuous delivery practises create the conditions for delivering value faster, sustainable.

• High performance is achievable whether your apps are green field, brown field, or legacy.

What are CI and CD?

• Continuous Delivery

• A software engineering approach in which teams keep producing valuable software in shortCYCLES and ensure that the software can be reliably released at any time

• Continuous Integration

• The practice, in software engineering, of merging all developer working copies to a shared mainline several times a day

• Changes to code automatically deployed to mainline branch

• After passing unit and mock tests

• Makes changes to code and deployments iterative, not monolithic

• Bugs are detected quickly

• Helps automate deployments

• Allows rapid development and deployment

Components of traditional CI/CD on AWS:

  Ø Deployment Software OnLAPTOP

  Ø Git Repository EC2 Instance

  Ø CI Software EC2 Instance

  Ø Project Management Software EC2 Instance

  Ø Build Artifacts S3 Bucket

AWS code services:

  Ø AWS CodeCommit

  Ø AWS CodePipeline

  Ø AWS CodeDeploy

Cloud software development lifecycle

CodeCommit: source control

  Ø Private Git repositories hosted on Amazon S3

  Ø Full Git compatibility (use with existingTOOLS)

  Ø All the benefits of the cloud  (scalable, durable, reliable, low pay-­as-­you-­go   pricing)

  Ø No size limits on repositories (store binary files)

  Ø Online web console

CodePipeline: continuous delivery

  Ø Customizable release automation, with integrated build and test

  Ø Model and visualize custom release workflow  (source e ->  build ->  beta ->  gamma -> prod)

  Ø Automate builds, tests, and deployments

  Ø Integrate with third-­party and custom tools

Deployment:

  Ø Coordinate software updates to fleets of EC2 instances

  Ø Rolling updates for no downtime

  Ø Deployment health checks and easy rollback

  Ø AutoSCALING integration

  Ø Works with any application

  Ø Reuse existing setup tools  (Bash, Powershell, Chef, Puppet…)

Cloud software development lifecycle

Components of CI/CD with AWS Code Services

  Ø AWS CodePipeline

  Ø Git Repository CodeCommit

  Ø AWS CodeDeploy

  Ø CI Software on EC2 Instance

  Ø Project Management Software EC2 Instance

  Ø Build Artifacts S3 Bucket