Saturday, March 11, 2017

CICD Assessment


( A story on -  how we formulated a process around measuring and achieving CICD, and  how these journey lines has now become a means to cherish and celebrate our collective achievement as 'one team', with a very transparent and clearly defined objectives )
----------------------------------------------------------------------------------------------------------------------------------------

CICD is the automation of Agile!

Last year we had setup a dedicated team to improve the CICD abilities for various teams across our organization.  The overall objective was to - 'Improve the speed of software delivery by implementing CICD practices and processes".

Primarily we focused on :
  • Implementing repeatable and reliable software release and deployment processes
  • Automate testing(s), builds, and deployments
  • Get everything in source control (not just code! Including config and control files)
  • No post deployment manual steps!  (Enables one click rollback when needed)
  • Software is NOT Done until “released and accepted”
  • And all these , with a shared vision that  - all stakeholders  (i.e. Dev, QE, OPS, RM, RE) will demonstration  equal responsibility for the release process!

When we set out on this  transforming  journey ,  we also wanted to measure this progress for various teams. My friend  'Alison Gabriel-Reilly' reminded of this phrase  : “You don’t know when you’ve arrived, if you don’t know your destination”

We looked around and could not find any such tool which we could use  to measure this CICD initiative  and also to capture  this progressive journey line for diff teams.


Essentially , our  need was : 

  • We should have a comprehensive list of all applications , which has an active SDLC track. ( worthy to mention  - we are an IT organization and many apps are in contained mode or waiting for sunset )
  • Consistent, holistic view of the initial overall status of various  applications for CICD
  • An ongoing means to measure and its subsequent improvement ( Continuous Improvement)

We quickly designed and exposed an evaluation URL , basically an internal tool ,  with an underlying  process defined , that -- as soon as we take up any of such CICD implementation work for any team or app , starting point would be to assess the current state.

Now talking about this tool, this is what the initial screen looks like:

[ Landing page ]


With this flow , once an app is selected from the drop down , we render an expanded view of four key pillars of CICD i.e. 'Continuous integration' , 'Test Automation' , 'Continuous Deployment' and 'Continuous Monitoring'.


Many people debated -  how can monitoring be an integral  part of CICD. The answer was simple:  if my Pre-Prod is down , my build pipeline is stuck.  And frankly , not many organization pay a focused attention on monitoring their Pre-Prod environments ; and CICD pipeline primarily encompasses your  Pre-prod.  When we have a final production ready release candidate , its a 'release' or  a 'release program charter'  , which solicits  all party approvals for a go/ no-go!  Which is decision driven, rather than an automated build & deployment flow.


Again , coming back to the tool , these compositions are nothing but some very fundamental, inherent elements aligned to those broader individual CICD aspects as said above. And for teams -  this now becomes  clearly defined objective(s) to strive and then achieve them progressively towards that big  uber goal of CICD.

The composition screen looks like this:

[ Calculate CICD score ]

We also introduced a very fun and exciting  element in this whole process , that -   you potentially can earn a 'badge' based on where you stand. and we display it at the organization level.


[ Badges as per the CICD score range ]


We also have a quarter wise QlikView dashboard , which the leaders of respective group(s) can keep a track of  their own team's CICD status , their progressive journey line, and continue to encourage them further.. 


 
[ Org level view ]



[ Journey line graph - Quarter wise , for individual app ]

Here I wish to mention that -  this entire thing has now become a proven and well established process for our entire org towards an ongoing means to measure and then take up the subsequent improvement steps for those teams/apps -  who has been aspiring to be on the CICD orbit ( i.e. Continuous Integration , Continuous Delivery )


With this tool,  and with these underlying scores  , it is really allowing us to understand -     the current CICD status of those teams or apps  ,  clearly envision the end state, track the ongoing progress in the CICD  journey and collectively agree on ( and act!)  -  where to focus our time and effort  towards enabling these team(s) to achieve complete CICD.

With this established process , these CICD journey lines has now become a means to cherish and celebrate our collective achievement as 'one team',  with a very transparent and clearly defined objective.


Be agile , deliver continuously! 
                                                                                    
 Thank you!!

Thursday, March 3, 2016

http/2



We probably all knew http/2.0 was in the making ( IETF have removed the minor version to avoid confusion, so you can just  call it http/2 or h2 )

Recently,     I had an interesting read on how the  industry is adopting http/2 ,   and below is just a loosely unorganized  excerpt with some useful links:

The current web fact is :     unlike late 90’s ,  every initial  landing page today on an avg. has 2 MB+  statics ( after compressed L)  , 125+ objects , ~52 RCP connections , and ~28 domains  embedded  – the need why the existing protocols are relooked.

Majorly  (i) multiple round trips , and (ii) nervous/jittery  congestion control design ,   from  the previous version i.e. http/1.1 was looked into,    and was the anchor point in this whole research.

·         Last year IETF passed the draft of http/2.
·         HTTP/2 was based largely on Google’s own protocol SPDY ( which will be deprecated  from May 2016 to give lead to http/2)
·         Currently 76%+  existing browsers supports http2 ( includes Mozilla, Chrome , IE etc. )

Main features for http/2:

-          Single Connection ( unlike http1.1) / avoid multiple round trip.
-          Multiplexing!
-          Server Push! ( proactively additional content can be sent to client for latter’s later use.
-          Binary and not text.
-          Header Compression ( uses HPACK compression)

See a demo:

·         http://www.http2demo.io
·         https://http2.akamai.com/demo

Does my site supports http2:    

You can actually check it here  :  https://tools.keycdn.com/http2-test  

Can we ?  :

Well, yes -  but do we really need it? Also,   It calls for  work on the existing infra. 
Apache 2.4.17+ onwards ships with mod_http2.


Some cool reads :

Patrick Stox here  , and  also, 'Stephen Ludin' from Akamai explains it more here on emerging web performance technologies.  

Who in the world has already adopted it ( see it here).

Thx/- Deba

Saturday, February 20, 2016

Auto-pilot teams!


At times we tend to question the role of a pilot above many thousand feets from the ground , when the plane is in 'auto-pilot' mode :)

“Your job as a manager is to make yourself redundant.”  - this is a very old line which has always been so very thought provocative for many leaders to cogitate and prepare to be one,  and by being  vulnerable at times.

Its always a 'win-win' when our team is 'self-sufficien't. 

 Self-sufficiency comes from empowerment and  empowerment should be via setting the right direction. 

I personally prefer a crack! team around me  :)  ( Creative/Collaborative , Representative, Authorized/Autonomous , Committed, and who is  knowledgeable - if at all you are wondering the expansion of 'CRACK' :) !! )

Self sufficiency combined with creativity, excellent collaboration skills and  mutual respect for each others builds a great working environment.
 
As a leader we should exhibit sincere behaviors which tells our team(s) that - I am  genuinely interested and  engaged with them in thoughts and spirits.  Sometimes it might be that - technically you are not able to coach or guide them - but with a very 'natural dialogue' we can speak about it.  Yes - I can not know everything in the world. 

Leaders, most definitely, cannot be successful without genuinely engaging in the work of others.

As a leader we should also try to drip our teams with the importance of 'curiosity'. Not every clock tick needs an invention, but - I have seen that with a ' culture of innovation' people often occupy their heads with 'good' thoughts and this only emits positive vibes and energies. So , don't forget to keep them occupied with right things. 

Sincerity fosters confidence. As a leader we must strive to be very open and transparent and willing to admit mistakes. Also remember that people don't like phonies.  People don't like deceitful behaviors and culture. Giving someone their due credit is the best thing a leader can do, and having that culture of recognition they feel more secured and more connected.

This kind of a culture is what propels a team to heights that even the leader doesn’t often foresee.

I don’t want , nor need people coming to me for every decision. I usually empower my peoples and have the expectations set and encourage them to make routine decisions. That is a big positive attribute and at the same time brings that challenge  -  how we keep a close tab on things then.

Rainbows does not last long and the other side of the rainbow might not have the gold pot all the time. 

So,  if this culture sees people debilitating a well set harmonious culture - by running rough shots over colleagues or subordinates ...  or something such,  we have to be equally vigilant too! There are office idiots who chronically complains   and  contributes more than what is needed and less than their potential.
Self sufficiency combined with creativity, excellent collaboration skills & mutual respect for others makes for a great working environment. - See more at: http://katenasser.com/leaders-do-you-prefer-self-sufficient-team-members/#sthash.EHrPjeCS.dpuf

 I have not seen what a pilot does during the 'auto-pilot' mode :)   - but for us,  with such  'self-sufficient' teams, we can definitely focus on things which will (only) bring more productivity in us,  and to the organization. 

-( Deba )

Self sufficiency combined with creativity, excellent collaboration skills & mutual respect for others makes for a great working environment. - See more at: http://katenasser.com/leaders-do-you-prefer-self-sufficient-team-members/#sthash.EHrPjeCS.dpuf
Self sufficiency combined with creativity, excellent collaboration skills & mutual respect for others makes for a great working environment. - See more at: http://katenasser.com/leaders-do-you-prefer-self-sufficient-team-members/#sthash.EHrPjeCS.dpuf

Self sufficiency combined with creativity, excellent collaboration skills & mutual respect for others makes for a great working environment. - See more at: http://katenasser.com/leaders-do-you-prefer-self-sufficient-team-members/#sthash.EHrPjeCS.dpuf

Tuesday, February 2, 2016

Disruption (vs) Disaster


Any disruption could have been stopped at some point with a proper Recovery Plan.  But then , when to call it a disaster?

 Disruption:
Incident < RTO
Impacts are limited and controlled
Disruption < $ (business determines threshold)

Disaster:

Incident  > RTO
Impacts are extensive and outside of your control
Disaster > $ (business determines threshold)

All of this requires Recovery Objectives to be identified prior.

-Deba

Saturday, May 23, 2015

the end is where we begin ..



What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from - T. S. Eliot


I have noticed in some meetings,  which are limited recurrings in nature - say: brainstorming , idea-jam's etc. where the entire 97% time goes very structured way.  But due to whatsoever reason - the last 3% of the time we rush so much that,  we actually end up very abruptly.   It defeats the whole momentum for the upcoming next, because you as a leader - did not think enough, and realize enough that its NOT the end of the ongoing series. And you will actually have to address the same audience in the very next upcoming one(yet again!).  Moreover,  if you missed to appreciate someone's effort in the current  in this hurry sickness  - you got a whole diff problem on hand now :-).  And I bet - you will be embarrassed on this act of yours!


By now you know where I am coming from.. Yes,  we should be very conscious about that last few minutes on such meetings, . and also create a visible and transparent agenda along with the need and importance of why we will be meeting again.   Leaders sowing the seed of curiosity!!

Also lets not forget to reiterate once , on - what is expected out of whom for the next and lastly - name the person who is going to send out the minutes ( MoM)  for today. Hope you had a official scribe ? :-)

So.. please try to maintain that momentum and enthusiasm - so that you  actually get a very good participants and some focused minds for the next one.  

Is not this 'end' is actually a beginning of the 'next'? You never know - those 'focused' minds may come up with some brilliant ideas by knowing -  what we are doing in the next huddle. This is looking forward and preparing ahead..  YES! the end is where we start from!!

-Deba

Separating alert DL from regular team DL



Most IT organizations usually keep it simple by sending all the alerts to everyone. This is still a sustainable model 10's or 20's of  systems.  However with more monitoring s added , the noise increases and the focus , attention and the rigor needed for the same ,usually starts dipping. 

Alert management and distribution is a real pain when done via email way. Hence , in absence of a dedicated DL for alerts there can be a lot of assumptions or unnecessary noise onto who is attending those or is it actually being taken care of.  We also get engaged in a unnecessary back and forth on query and answering mode - rather then paying attention to the real issue in hand.

Typically in any organizations - we just have a few dedicated resources who jumps onto such incidents/issues real fast , and that too -with an honest intention to solve it for the organization. Hence providing a conducive environment for their work is indeed a prime importance. 

Moreover , separating alerts DL from the primary email DL could be a very good practice,  specially when you have other people who are not responsible for attending OR acting on such alerts. Also on the flip side - it can be so very noisy for those members,  who will go on an never ending stride being part of that DL. Because - important emails might get lost when there is are flurry of alerts.  Of-course you can filter those alerts - then why should you be part of that DL(alert) anyway?

Tip:

1. Keep a primary group DL , which is for regular business communications and discussions.
2. Keep separate DL for alerts - and keep ONLY those engineers, who is accountable for triaging day to day alerts or OnCall related issues.

-Deba

Git (Vs) GitHub





Git is a revisionor version  control system, a tool to manage your source code history.

In the SVN analogy, Git replaces SVN, while GitHub replaces SourceForge.  So , essentially - GitHub is a hosting service for your Git repositories. And , most notably, GitHub is a consequence of the existence of git and not the only hosting service.

For folks who are new to GIT , this is an absolute awesome 15 min. refresher.

-Deba 

CICD Assessment

( A story on -  how we formulated a process around measuring and achieving CICD, and  how these journey lines has now become a means t...