Continuous Delivery WhitePaper

Continuous Delivery in a Nut Shell

Whatever may be the type or size of the industry, transformation is the key to improvement. Continuous Delivery (aka CD) is emerging as the front runner in the race of transforming IT business from “Slow Delivery” to “Quick and Reliable Delivery”. In combination with right Agile methodology, CD is helping companies to reduce time from planning to production and hence allowing them to earn cash for their product/services faster and with better margins.

What’s in it for Me?
CD has something for everyone in different teams, product, companies or domains. For engineers in any domain (from textile to Software) it means to automate production plan and shipping finished product/services to customer faster and on regular intervals.

CD for Software Development.
From Software Development perspective, CD is divided in 5 components.

#1: Configuration Management. “Single Source Of Truth”
#2: CI and Build Management. “Early and Often”
#3: Testing. “Early, Repeatable and Ever Improving”
#4: IT and Infrastructure Management. “On-Demand and Scalable”
#5: Release Management. Ship Right Release at Right Time”

To set things right CD evolved with 8 basic principles.

Principle #1: The process for releasing/deploying software MUST be repeatable and reliable.
Principle #2: Automate everything possible!
Principle #3: If something is difficult or painful, do it more often.
Principle #4: Keep everything in source control.
Principle #5: Done means “released”.
Principle #6: Build quality in!
Principle #7: Everybody has responsibility for the release process.
Principle #8: Improve continuously.

Summary in a Nut Shell. 

* Special thanks to  David Farley & Jez Humble (as some text of this post is sourced from their book "Continuous Delivery")

Good to be Agile

It's been a long time that I wrote any blog, so now here I am again.
This time I think the best topic to share is working with Agile methodologies.

It's been more than four year now that I have been working with the same. Some initial questions may occur in the mind of the reader of this blog.

Questions like:
- What is actually AGILE?
- How can it make my work better?
- What are it's pros and cons?
- etc. etc.

By definition agile means quickly producing something useful and improving it over a period of time to the best of it's type.
But quick doesn't means to forget the real iterations required for the process.

I will put an example here:
Suppose you are developing a software, under waterfall model we start coding finish the project over a period of time and pass it to the customers.
But in agile we start coding get some thing usable (something like a prototype) pass it to the customers, then start improving it (taking help from customer's feedback). This ends up in a better end product as it includes customers feedback also. And a software which has passed phases like creating prototype, testing, retrofitting etc. (real time iterations), is of greater value to the customer.

There are various Agile methods, our need defines as which one will suit us the best. Example:
KANBAN:  A method for developing products and processes with an emphasis on just-in-time delivery (using KAN="Visual" BAN="Board" technique) while not overloading the developers. With proper use of Kanban, projects are able to eliminate bottlenecks from any part of development cycle.

SCRUM: It is an iterative and incremental development process, where effort is tracked by burndown charts (each sprint) and Velocity tracking (over many sprints). These metrics help in better, predictable sprint planning and hence delivering happy faces.

In the Soup

As trying to consolidate all my accounts under one roof, I tried migrating my blogs from Yahoo ID to Gmail ID.
But what a mess, I could only migrate the posts and not the profile data. I lost data like as "Since when I have been blogging" etc.

Hoping to get such feature in blogger.com which would allow to change Username OR the User ID without loosing blog stats.

Google Apps Active Directory sync.

Are you planning to migrate from MS suit to Google Apps?

Some time back I did one such migration and came across several posts where people said "Google AD sync doesn't work properly", etc etc.

But I found it very useful and usable, with a fact that not much of the documentation is available around it.

This lack of documentation inspired me to write this blog, hopefully it will ease up your work.

To begin with, you need to have:
* Working MS AD and an account with Google App
* Administrative credentials for both (AD and Google App) accounts.
* "Google Apps Directory Sync tool" installed on your system.

Now lets see how it is done:
* Start the "Configuration Manager" from your startup menu.

* Fill the required details as shown in screenshots.

General Settings: Check the options that you want to migrate to Google Apps. In my case I used only Users and Groups.

Google Apps Settings: Fill the email and password of user with Administrative privileges on Google Apps.

LDAP Connection: This part needs your local LDAP/AD details. The provided user nay not be admin, but needs only read access.

User Attributes: Provide the local (LDAP/AD) attribute for mail ID (in my case it was mail).

User Extended Attribute:  This configuration maps local given name, sir name and password attributes to Google Apps.
Specifying Suspension Policy enables the user to decide what to do if a user is present in Google Apps and not in local AD.

User Sync: Add a new rule. This rule will define which users to sync (or which user not to sync). The rule field accepts RegEx, allowing us to add multiple users through one line.

Notification: In this section define your SMTP server and other details required to relay email on success or failure of this sync up.

Sync Limit: This section is to specify the suspension limit. In simpler words "The script should fail if more users are being suspended (than the specified limit)".

Log File: Specify a valid log file path here. The sync tool will save its output in this file.

Anything Else: There are many more options available (example syncing contacts etc), but in this blog I documented only the minimalistic configuration (and that was what I required fro my project).

* Test it out.

Simulate Sync:  This tab will tell you if your configuration is correct. And if you don't find any error (warnings are still OK), then just hit "Simulate Sync" @ the bottom.

Result: Hitting Simulate Sync will take you to a new view. Check if you see users being synced and you don't have errors.


* Save this configuration to a file. I saved it as google-sync.xml.

* Run it: As of now this sync can only be run through command line, so just run this command and see the magic.

sync-cmd.exe -a -c "google-sync.xml" -r C:\Sync-logs\Google.Sync.logs

* Schedule it with the help of tool like Jenkins and you are done with one aspect of migration which gives head ache to people.

PS: Scheduling it through a tool makes it easy to monitor and/or run it on demand.

I am confused (Google docs Vs Dropbox)

One of the interesting thing that I worked recently on was a small decision of either using Google docs or Dropbox for storing and sharing documents.

Seems unimportant?

I also thought the same on hearing this for the first time, but believe me this proved to be an interesting study.

Let me take you to the tour of both.

Google docs is an online solution provided by Google to collaboratively work (sharing, editing, etc) on the documents.
  Several addons like Cloud Connect, etc helps us to sync our native MS office documents to Google docs.
One of the advantage of Google docs is that multiple people can edit one single document @ the same time.

On the other hand Dropbox is used to share files, irrespective of the file being a document, image or some thing else.
Same account can be either synced to multiple computers OR same files can be shared to multiple accounts, hence giving feasibility of accessing the files across the globe (on multiple systems).
Feature like sharing and selective sync help us selective share our files with different people.
One of the advantage of Dropbox is the ability to share all sorts of files (not only just documents)

And the confusion starts :-)

It looks pretty simple that Google docs should be used for documents and Dropbox for other files, but the problem statement lies in the fact that Google changes format of our existing MS office/Open office  documents to Google docs format (on uploading). In most of the cases this is not an issue, but it created trouble when you have formulas, macros and images in your documents, as
"They may disappear from your uploaded document".
Google also provides a solution to this, in the form of uploading the documents (in this case other files can also be uploaded) in original format (not changing the format to Google docs format).

Here comes another "BUT".

But this also has a drawback, that we can't maintain single source of truth for the documents. To edit any document we have to download it and then again upload, which creates multiple copies in Google docs (which have to be manually deleted).

Conclusion after digging deaper:
Using any of these tool is subjective.

IF:
* You are creating the documents from scratch.
* And the priority is to have simulanious editing of documents, rather than maintaing MS office formatting, example: Attendance sheet etc.
Then Google docs is THE tool.

ELSE IF:
* You want to use your existing docs.
* And the priority is to use the MS office format.
Then Dropbox is THE tool.

Advantages:
* Google can save money sent on MS office licenses.
* Both the tools can save the hassle of maintaining local shared file server.
* Both have there recovery mechanism, so no danger of getting fully F**k*d.
* Both provide full fleged files/documents sharing system (sharing sccross the globe).
* Both provide the confidence of having one single "Source Of Truth" for documents.
* Dropbox provides offline editing of files (as they gets synced when connected back to internet). Same is provided by Google docs when used with Cloud Connect.

As my requirement was more of sharing and offline working, so I choose Dropbox for now :-)

Cross Platform scripting with bash.

Is this title a bit confusing?

I asked this question to many people and got the same answer as "YES"
In our day to day life when we talk about bash, we refer to Linux as it's OS.

But the main punch of this blog is to mak BASH break the boundaries of Operating System.
I agree that till now bash is not capable of doing this alone.

Now any guesses about the tool?

If you guessed "CYGWIN" then consider yourself as winner ;-)

To make it more clear for people who were not able to guess it, I can put my example here:

Background: I am a consultant and work with all sorts of projects, during my last couple of projects I was automating build & release cycle for a product that is built on four platforms (Linux32, Linux64, Windows32, Windows64), hence I was desperately looking for some cross OS/platform scripting solution.

My Thoughts: I am a BASH guy and as any developer, my first preference was to look for a solution around what I already know, rather than straight away jumping into any new technology and learning it (it was my second option though).
If it was not bash then I was looking into ant or others to do the job.
As
"The best way to do a work, is to do it." --Harpreet Singh

For Newbies: Cygwin is Linux-like environment for Windows making it possible to port software running on POSIX systems (such as Linux, BSD, and Unix systems) to Windows.

Solution: Now lets put this together.
Install Cygwin on a windows system with basic features like "openssh", "vim", etc.
That's it you are ready to rock 'n' roll.
All most all your Linux commands can run in this shell, which includes doing "ssh" into a Windows system ;-)

Need More: The story is not over yet. Combining the above setup with a CI tool (Jenkins in my case), gave me what I wanted.
A full fledged automated build system, running on four platforms simultaneously (using Jenkins' multi configuration project feature), with ease of writing the script only once and that too using BASH.

Now that's what I call a win ;-)

The winners prize: As a prize of my effort done for the above setup I got:
* Time saved per build/release cycle.
* Time saved in developing automation scripts.

And more important a "Happy Client"