What is..?

Jenkins is a tool (web application ) that helps in continuous integration of projects. It is open source and has capability to manage any types of build software. Jenkins can be seamlessly integrated with any testing and deployment environment.

Continuous Integration.

In software developement life cycle, there are various pahses of the software developement. In developement there may be checking in the code, modifying the code, testing, deployment , bug fixes etc. Continous Integration is a practise that requires developers to integrate code into a shared repository at regular intervals. The code can be checked in from various central repository such as GIT, SVN, CVS. They may be modified as per the requirements. Continious Integration is a practise that whenever a code commit occurs, the build process should be triggered.

How to get jenkins.

Jenkins can be downloaded from Then it may be run from the command line using the java -jar command. It may be put in the application container such as tomcat, jboss, weblogics etc.

Once the Jenkins application is deployed in the machine, it has to be configured with the project repository, build tool (maven, ant etc) build time, testing configuration , email configuration etc.

After the above configuration is set , Jenkins create a disk-space to store all the projects, dependencies etc in a directory ~/.jenkins (default location). We may also change the location by setting the JENKINS_HOME environment variable before launching the servlet container.


Email Notification.

Jenkins also sends the email notification when any deployment event occurs. These email feeds can be managed in the email notification area. There is a provision to configure the SMTP settings for sending out emails.



Jenkins ships in with many plugins to build project, manage project, add security, add user and organization level profile, etc We may also add plugins build for jenkins systems.

Manage Plugins screen helps to install, update and remove plugins.

What is DevOps in SDLC?

What is DevOps in SDLC?

There are lots of opinions about what is covered under DevOps and what’s not. Is it a culture? Is it a job title? Is it a way of organizing? Or just a way of thinking? We think it’s a still-evolving movement so let’s not get stuck on limiting it too much right now. Instead, we can talk about some of the common themes, tools and ideas.

DevOps is a software development method that emphasizes communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other IT professionals.[1][2] The method acknowledges the interdependence of software development, quality assurance (QA), and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.

In simple words, DevOps means a software development method which stresses on communication, collaboration and coorperation between software developers and other IT professionals.


“Venn diagram showing DevOps as the intersection of development (software engineering), technology operations and quality assurance (QA)”

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. It is also characterized by operations staff making use many of the same techniques as developers for their system work.

The Perfect Storm of 2009.

A perfect storm of converging adjacent methodology including Agile, Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN and IT Service management came together in 2009 through a smattering of conferences, talks and Twitter (#devops) debates worldwide that eventually became the philosophy behind DevOps.


Agile software development paved the way, steering away from the waterfall method of software development toward a continuous development cycle. But it didn’t include the operations side so while development could be continuous, deployment was still waterfall-oriented.

In a DevOps environment, cross functionality, shared responsibilities and trust are promoted. DevOps essentially extends the continuous development goals of the Agile movement to continous integration and release. In order to accommodate continuous releases, DevOps encourages automation of the change, configuration and release processes.

DevOps tools.

The Agile Manifesto emphasizes individuals and interactions over processes and tools, but DevOps, while emphasizing collaboration and integration also looks to automation tools that can leverage an increasingly programmable and dynamic infrastructure from a lifecycle perspective. Version control and automating code deployments are two of the most impactful common tools but there are many more, including configuration management, ticketing systems, monitoring and provisioning.

Benefits of DevOps

Companies that incorporate DevOps practices get more done, plain and simple. They deploy code up to 30 times more frequently than their competition. And less than 50% of their deployments fail according to Puppet Labs 2013 State of DevOps survey.

The biggest shift in attitude in a DevOps environment is that there is one team composed of cross-functional team members including developers, QA, DBAs, business analysts,operations engineers and so forth. Collaboration across these different roles delivers many benefits.

Technical benefits:

  • Continuous software delivery
  • Less complex problems to fix
  • Faster resolution of problems

Business benefits:

  • Faster delivery of features
  • More stable operating environments
  • More time available to add value (rather than fix/maintain)

Practical Illustration from an entrepreneur

Gene Kim, a software researcher/ entrepreneur and one of the authors of the book “The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win”. In which he shares anecdotes about how Operations engineers work really long hours to keep production systems up and running.

Lesson 1: Business value of DevOps is undervalued.

Many leading technology providers, retailers, manufacturers, government organizations and higher educational organizations are currently using DevOps principles and practices and thereby increasing success rate and profitability.

To support the above fact, Gene shares the following statistics:

· The companies with DevOps do more frequent deployments with smaller changes and lesser preparation; they have higher lead times than peers.

  1. 30 times more – frequent deployments
  2. 8000 times faster – lead times than peers

· High performers are more agile and more reliable.

  1. 2 times more – change success rate
  2. 12 times faster – mean time to recover

· High performers win in the Marketplace.

  1. 2 times more likely to exceed profitability, market share and productivity goals
  2. 50% higher market capitalization growth over 3 years.

Lesson 2: DevOps is as good for Developer as it is for Ops Engineers

In 2008, for the rollout of Facebook chat, Facebook had been testing the messaging in production for over a year before they released Facebook chat for 98 million users, overnight, without a hitch. Testing in production with frequent fixes was proved to be successful for a large-scale rollout like Facebook chat.

Lesson 3: The need for high-trust management

In 2012 the company, Knight capital group, had a 15-minute deployment failure that caused 440 million trading loss and the company had to be sold immediately over the weekend4.

Two possibilities were reported for the failure:

(i) Change control failure

Change control team could’ve had quick detection of the failure and recovery mechanisms.

Management’s reaction:

Add one more level of approval authority.

Phoenix project’s take on this:

The number (levels) of approvers increases => implies or leads to => Deployment engineer or developer not empowered to take dynamic decisions during the deployment => multi million-dollar losses.


Considering the person doing the deployment knows the most about the code change, he must be empowered to take any dynamic decisions during the deployment.

(ii) Testing failure

Proper testing could’ve enabled earlier detection of the failure and prevented it from happening.

Management’s reaction:

Do more testing.

Phoenix project’s take on this:

More testing => longer development cycles => less frequent deployments => bigger chunks of changes in each deployment than before => deployments are more prone to errors.


Do the deployments more frequently, with smaller chunks of changes.

In most scenarios, management would disagree with the above resolutions because of low trust. Thus there is an imperative need to transform low trust organization culture to high trust where people are empowered to deliver software in safe environment.

Lesson 4: DevOps is not just for unicorns (Google, Facebook etc.) it is for horses, too.

Gene gives anecdotes of number of companies (other than the unicorns) that are using DevOps principles and thereby drastically reducing their lead-time from commit through testing through production deployment. Reducing deployment intervals decreases preparation time and technical issues, and increases product efficiency and customer satisfaction.

I will discuss on the DevOps lifecycle and other practical examples which illustrate improvised SDLC processes in my next blog.

References –


Software Development Life Cycle (SDLC):

Software Development Life Cycle (SDLC):

Our focus here about software development life cycle (SDLC). So, due to that different types of projects have different requirements. 

SDLC aims to produce high quality systems that meet or exceed customer expectations,reaches completion within times and cost estimates. based on customer requirements, by delivering systems which move through each clearly defined phase.

Definition:SDLC is the process in which software project is developed in systematic and scientific manner to ensure quality to the project.

SDLC contains six phases they are

  1. Initial/ requirements gathering phase.
  2. Analysis phase
  3. Design phase
  4. Coding Phase
  5. Testing Phase
  6. Delivery & Maintenance Phase.


1) Initial/Requirements gathering Phase:

Roles:   Business analyst (BA)
Engagement manager (EM)

Process: First of all the business analyst(BA) will collects the templates from the company, meets the customer on appointed day, gathers the requirements with the help of template. The engagement manager (EM) will check whether the customer given any extra requirements or confused requirements. In case of extra requirements, he deals the excess cost of the project. In case of confused requirements, again they will gather the requirements clearly.
Proof: The proof document of this phase is Business Requirement Specifications (BRS). It has different names in different companies.

  • FRS (Functional Requirements Specification)
  • CRS (Customer Requirement Specification)
  • URS (User Requirement Specification)
  • BDD (Business Design Document)
  • BRD: Business Requirement Document.

Templates: It is a pre defined format, which contains the predefined fields, and used for preparing a document in an easy, comfort and perfect manner.

2) Analysis Phase:In this phase BRS is used to do analysis
Roles: System Analyst
I) Feasibility Study: It is detailed study of the requirements in order to check whether the requirements are possible or not.
II) Tentative planning: In this section the resource planning and the time planning (scheduling) is done temporarily.
IIA) Technology Selection: The list of all the technologies that are required to accomplish this project. Successfully will be analyzed and listed out in this section.
IIB) Requirement Analysis:The list of all the requirements that are required to accomplish this project. Successfully will be analyzed and listed out here in this section.
Proof: The proof of this phase is “System Requirement Specifications (SRS)”.

3) Design Phase: To develop the blue-print (design) for the project development.
Roles:  Chief Architect (CA)
            Technical Lead (TL)
I) High level designing
II) Low level designing
High-level designing is done by the chief Architect (CA) ,he will be drawing some diagrams using unified modeling language in order to divide the whole project in to modules.
Low level designing is done by the Technical Lead (TL),he will also draw some diagrams in order to divide the modules in to sub modules.
Proof: The proof document of this phase is “Technical design document (TDD)”.

4) Coding phase: Developing or Programming (Implementation of the design)
Roles: Developers or Programmers
Process: Developers will develop the actual code by using the technical design document as well as following the coding standards like Proper indentation, color coding, proper commenting and etc.. as per company requirements.
Proof: The proof document of this phase is” source code Document (SCD)”.

5) Testing Phase: validate the functionality through make it defect free.

Roles: Test Engineers
Process: Testing process is associated with following steps

I) BDD Review: First of all the test engineers will collect the requirements document and try to understand all the requirements
II) Preparation of Review Report: While understanding it at all they get any doubts they will list out all of them in a review report.
III) Sending Review Report to BA: They will send the review report to the author of the requirements document for clarifications.
IV) TCD Preparation: Once the clarifications are given and after understanding all the requirements clearly, they will take the test case template and writes the test cases.
V) TCD Execution: Once the build is released then they will execute the test cases
VI) Identification of bugs and Isolation of bugs: If at all any defects are found. They will list out all of them in a defect profile document (DPD)
VII) Bug Reporting: They will send the DPD to the development department and then will be waiting for the next build to be released.
VIII) Once the next build is released then they re-execute the test cases.
IX)If at all any defects are found they will update the profile document and sent it to the development department and will be waiting for the next build to be released.
X)This process continues till the product is defect free.

Proof: The proof of the testing phase is Quality Product.
Test Case:  Test case is an idea of a test engineer based on the customer’s requirements in order to test a particular feature (or) a function.

6) Delivery & Maintenance Phase:

Roles: Deployment engineer/ Software Quality manager/ Project Manager
Delivery: To deliver the product to the client.
Task: Installing the application into the client’s environment
Process: deployment engineer will go to the client’s place and install the application in their environment.

Documents associated with the delivery process:

  • Certification document (to ensure its quality)
  • User manual (to guide the user how to use it)
  • Deployment document (to guide the user how to install it)


Some clients may request for the continuous maintenance in such situations a group of people from the software company will be continuously working on the clients place and taking care of the software.