Start­ing the DevOps Jour­ney Us­ing Cu­cum­ber and Se­le­nium

DevOps is a soft­ware build­ing process which em­pha­sises com­mu­ni­ca­tion and col­lab­o­ra­tion be­tween the teams in­volved in prod­uct man­age­ment, soft­ware de­vel­op­ment, and op­er­a­tions. Cu­cum­ber is a be­hav­iour driven de­vel­op­ment tool, which when com­bined with Se­leni

OpenSource For You - - Developers -

It is of­ten said that con­tin­u­ous change is the law of the uni­verse and the same is true in the soft­ware in­dus­try. We have seen a va­ri­ety of soft­ware de­vel­op­ment mod­els, start­ing from Wa­ter­fall, V and spi­ral mod­els to the in­cre­men­tal op­tion. All these mod­els have dif­fer­ent re­quire­ments and guide­lines and suit dif­fer­ent sce­nar­ios. These days, most or­gan­i­sa­tions have em­braced the Ag­ile method­ol­ogy for soft­ware de­vel­op­ment.

The Ag­ile method of de­vel­op­ing soft­ware and ap­pli­ca­tions fo­cuses on de­liv­er­ing high qual­ity prod­ucts fre­quently and con­sis­tently, which leads to an in­crease in busi­ness value and prof­its.

Ta­ble 1 lists the dif­fer­ences be­tween the Wa­ter­fall and Ag­ile soft­ware de­vel­op­ment ap­proaches.

You can see that the Wa­ter­fall model can cause over­shoot­ing in time and re­sources, which can lead to huge losses to the com­pany in terms of prof­its and user sat­is­fac­tion. To avoid this, or­gan­i­sa­tions have started adopt­ing the Ag­ile model. There are other rea­sons too, for choos­ing this model, some of which are listed be­low.

Client en­gage­ment: In the Ag­ile model, the client is en­gaged in the soft­ware de­vel­op­ment process at ev­ery step — be­fore, dur­ing and after the sprint. This helps the de­vel­op­ment team to un­der­stand the client’s vi­sion clearly so that de­fect-free and high qual­ity soft­ware can be de­vel­oped and de­liv­ered in less time.

Trans­parency: Since the client is ac­tively in­volved in all the sprint ac­tiv­i­ties, rang­ing from fea­ture pri­ori­ti­sa­tion and plan­ning to re­view­ing and, fi­nally, to de­ploy­ment, this

en­sures trans­parency to the client. Timely de­liv­ery: Usu­ally, the du­ra­tion of a sprint is fixed and varies be­tween one and four weeks, which forces the team to de­liver fea­tures rapidly and fre­quently. This also helps prod­uct own­ers to pre­dict the costs in­volved in the de­vel­op­ment and keep these un­der check.

Chang­ing re­quire­ments: The Ag­ile method­ol­ogy also al­lows teams to in­cor­po­rate changes in the re­quire­ments at an early stage of the de­vel­op­ment cy­cle, which helps com­pa­nies to de­velop high end prod­ucts with­out over­shoot­ing their bud­gets.

User fo­cused: In­stead of test cases, the Ag­ile model em­ploys user sto­ries that have busi­ness and user fo­cused ac­cep­tance cri­te­ria. This helps teams to un­der­stand the needs of the users and de­liver prod­ucts that can be beta tested in time, so that the nec­es­sary changes can be done at the ear­li­est.

Steps in the Ag­ile ap­proach

Let’s look at the steps in­volved in im­ple­ment­ing the Ag­ile method­ol­ogy.

1. Dis­cov­ery: To de­velop a high qual­ity prod­uct, one needs to have a clear vi­sion and con­sid­er­able ex­pe­ri­ence in the tech­nol­ogy used in that project. Dis­cov­ery ses­sions are sig­nif­i­cant, since they are the ba­sis for all the up­com­ing ac­tiv­i­ties in the sprint. Dur­ing these ses­sions, the clients’ goals, the users’ ex­pec­ta­tions and the busi­ness chal­lenges are un­der­stood deeply so that no am­bi­gu­ity re­mains in the minds of the team, re­gard­ing the prod­uct.

2. Prod­uct back­log: The re­sult of suc­cess­ful dis­cov­ery ses­sions is prod­uct back­log, which con­tains a list of all the fea­tures that need to be de­vel­oped. These fea­tures are then clas­si­fied on the ba­sis of pri­or­ity by the prod­uct owner (in dis­cus­sion with the client), so that high pri­or­ity fea­tures can be de­vel­oped, tested and de­liv­ered first. 3. It­er­a­tions: After the high-level prod­uct back­log is fi­nalised along with the pri­or­ity, sprints are planned and work be­gins on the fea­tures men­tioned in the back­log.

4. Cy­cle: If all the fea­tures are com­pleted and tested suc­cess­fully, then the cy­cle stops; oth­er­wise, ad­di­tional sprints are planned to carry out the re­main­ing work.

Ag­ile and DevOps: The con­nec­tion

Ag­ile and DevOps – these two terms have be­come the buzz­word these days. Though these two words are used in­ter­change­ably, there’s a stark dif­fer­ence be­tween them. Ag­ile is mainly con­cerned with soft­ware de­vel­op­ment and the pro­cesses or steps in­volved in it, whereas DevOps comes into the pic­ture after a high qual­ity prod­uct has been de­vel­oped, i.e., it is about the de­ploy­ment and man­age­ment of soft­ware. The term DevOps is de­rived from two words – de­vel­op­ment and op­er­a­tions. Be­fore delv­ing deeper into the details of DevOps, let’s see how it emerged in the IT scene.

We have seen how or­gan­i­sa­tions reaped ben­e­fits by im­ple­ment­ing the Ag­ile method­ol­ogy, but this model also had some hitches, which are listed be­low:

There were chances of in­com­pat­i­bil­ity be­tween old fea­tures and new fea­tures dur­ing in­te­gra­tion. Of­ten, bud­get goals and dead­lines were missed.

There was a lack of co­op­er­a­tion be­tween the de­vel­op­ment and IT op­er­a­tions teams.

Usu­ally, when­ever any prod­uct is re­leased or any ser­vice is made live by an IT or­gan­i­sa­tion, two de­part­ments come to­gether to sup­port this re­lease – the de­vel­op­ment and op­er­a­tions teams. Yet, there is a lack of co­or­di­na­tion be­tween de­vel­op­ment ac­tiv­ity and op­er­a­tions ac­tiv­ity. The de­vel­op­ment team feels it is be­ing paid to bring about ‘change’, whereas the op­er­a­tions team is look­ing at sta­bil­ity and con­sid­ers ‘change’ its en­emy. This con­flict in mind­sets of­ten leads to in­ef­fi­ciency and over­head costs for the com­pany. DevOps is a prac­tice em­ployed to smoothen the IT ser­vice de­liv­ery by pro­mot­ing com­mu­ni­ca­tion be­tween de­vel­op­ment and op­er­a­tions teams, which is es­sen­tial to in­crease a com­pany’s pro­duc­tiv­ity. It helps the com­pany to con­tin­u­ally de­liver soft­ware with highly sta­ble fea­tures, faster and more fre­quently.

DevOps brings more flex­i­bil­ity to the Ag­ile method­ol­ogy and lever­ages its pro­duc­tiv­ity. It widens the scope of

Ag­ile prin­ci­ples by in­clud­ing op­er­a­tions teams in its am­bit in­stead of stop­ping the Ag­ile cy­cle at code check-in only.

So, you can de­duce that Ag­ile prin­ci­ples and pro­cesses can be em­ployed as a part of DevOps. In lay­man’s lan­guage, we can say that by us­ing the Ag­ile method­ol­ogy, high-end prod­ucts are de­vel­oped and by im­ple­ment­ing DevOps, the de­vel­oped prod­ucts are de­ployed in a timely man­ner. So the Ag­ile model and DevOps com­ple­ment each other, but are to­tally dif­fer­ent from one an­other.

De­vel­op­ment Team Op­er­a­tions Team

Fig­ure 1: Ag­ile and DevOps com­ple­ment each other with the sup­port of the QA and IT op­er­a­tions teams

I want change! I want sta­bil­ity! Fig­ure 2: Wall of con­fu­sion be­tween the de­vel­op­ment and op­er­a­tions teams

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.