Installing & configuring Git on Fedora

First thing first - Let's install git. There are two major ways we can install git 

• install from an existing package
• install it from source or

installing from an existing package: Easy, Open up Terminal and type the following command:

$ sudo yum install git-core ~/.ssh
$ sudo password for username: type your password here 

installing from source: It’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.

To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora), you can use the following command:

$ sudo yum install curl-devel expat-devel gettext-devel\
openssl-develzlib-devel

Once the installation is done you can do

$ git --version

this will show the version of Git you are using.

Now that you have Git on your system, you'll need to configure Git to use it. Following step you need to follow for configuring but before we start I am assuming that you already have a github account, if not please create an account in github.

Step 1: Check for SSH keys

First, we need to check for existing ssh keys on your computer. In the Terminal, type:

cd ~/.ssh
ls
# Lists the files in your .ssh directory

Check the directory listing to see if you have a file named either id_rsa.pub or id_dsa.pub. If you don't have either of those files go to step 2. Otherwise, you already have an existing keypair, and you can skip to step 3.

Step 2: Generate a new SSH key

To generate a new SSH key, enter the code below. We want the default settings so when asked to enter a file in which to save the key, just press enter.

ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair.
# Enter file in which to save the key (/home/you/.ssh/id_rsa):
ssh-add id_rsa

Now you need to enter a passphrase.

Enter passphrase (empty for no passphrase): [Type a passphrase]
# Enter same passphrase again: [Type passphrase again]

Which should give you something like this:

# Your identification has been saved in /home/you/.ssh/id_rsa.
# Your public key has been saved in /home/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com

Step 3: Add your SSH key to GitHub

Run the following code to copy the key to your clipboard.

sudo yum install xclip
# Downloads and installs xclip. 

xclip -sel clip < ~/.ssh/id_rsa.pub
# Copies the contents of the id_rsa.pub file to your clipboard

Alternatively, using your favorite text editor, you can open the ~/.ssh/id_rsa.pub file and copy the contents of the file manually.

Now you to open the Browser and perform the following steps 

1. Go to Github Account Settings
2. Click SSH Keys in the left sidebar
3. Click Add SSH Key
4. Paste your Key into the Key field
5. Click Add Key
6. Now Github will prompt you for your github password to Confirm the action.

Step 4: Test everything out

To make sure everything is working you'll now SSH to GitHub. When you do this, you will be asked to authenticate this action using your password, which for this purpose is the passphrase you created earlier. Don't change the git@github.com part. That's supposed to be there.

ssh -T git@github.com
# Attempts to ssh to github

You may see this warning:

# The authenticity of host 'github.com (207.97.227.239)' can't be established.
# RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
# Are you sure you want to continue connecting (yes/no)?

Don't worry, this is supposed to happen. Verify that the fingerprint matches the one here and type "yes".

# Hi username! You've successfully authenticated, but GitHub does not
# provide shell access.

If that username is correct, you've successfully set up your SSH key. Don't worry about the shell access thing, you don't want that anyway.

Well we are done! Hope this helps.

A Practical Guide: Story Points-Based Estimation

Glad to see that my article made it +Scrum Alliance

http://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation

The road to Continuous Delivery

Continuous Delivery it's a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated and/or acceptance tests on it and testing the release process itself.

Practicing Continuous Delivery gives you several advantages:

+The time from idea to deployment to production (cycle time), is shortened.

+By shipping the product early you are encouraging early feedback. The faster you get your software to your end-user, the faster you get feedback.

+You’re always ready to deploy to production. You do not have to spend time making and testing a release.

+Because you’ve already tested the release process itself, deploying to production is simple and error-free.

+You are getting ahead of the competition and making your release process a business advantage.

How to implement ?

• Ensure both your developers and system administrators are responsible for deployment. Traditionally, the system administrator is responsible for deploying to production. By making your developers responsible too for deployment you are encouraging a culture of collaboration (DevOps) and lowers the chance of errors due to miscommunication.
• Find out what your release process looks like, make it reliable and repeatable and automate as much as possible. Make every step of the process reliable and repeatable. When your steps are reliable and repeatable, then they can also be automated. As our goal is to automate each step.
• Setup one single way of deployment to an environment. Make sure that you define a single way to deploy a release to an environment, whether is it the test environment or to production. If you do this, then you’re also testing your deployment process itself.
• Test on a production-like environment. If you test on a different environment than your production environment, then there is a risk that your deployment to production doesn’t work or worse: your end-users experience runtime problems due to different software versions of third-party software and libraries.
• Quality first Keeping your application deployable should get higher priority than adding new features. If an error in your release process occurs, fix it as soon as possible.

Where do I start ?

It takes effort to fully practice Continuous Delivery. But you may start slowly by:

• Let your developers and system administrators work together on deploying your application.
• Visualize your release process.
• Make steps of your release process reliable and repeatable