DevOps. On the ground.

While DevOps brings Dev, QA and Ops – both infra and service management guys – together, how do you realize it on the ground? So, here you go (however, you will still need to get experts who practice it, and related technologies, day in and day out):
1. Lets’ start with people first. The simple straight point is to have Agile scrums – with daily stand-up meetings (assuming that either the team is co-located, or can see each others’ faces over a video-con in case of remote/ virtual teams) – involving representatives, though preferably all in the one-IT team, from Dev, QA and Ops. They all need to know what others are doing, and hence are all collectively responsible for quality as well as meeting the timelines together.
2. Cross-skill Dev, QA and Ops. Why? Because, in case there is suddenly a spurt of one activity over the other, each can help out the other. For example, once infra provisioning has been done, the infra guy can join the QA guy (and same goes for Dev, as that guy has not yet started coding) to create the test scripts. This is what we call as self-organizing teams.
3. Lets’ now talk about the processes. Shift-left Ops – infra. What does that mean? This is quite obvious that unless infra (with relevant environments) are provisioned, Dev or QA cannot start their work effectively. Writing code on paper does not help much. That’s why, once the change request or requirements flow in, discuss and align during the stand-up the exact requirements of infra and environments that need to be provisioned. Once the infra guy goes back to the desk, he/she immediately gets on to the job.
4. Shift-left QA. The test scripts should all be ready before Dev takes over writing any code, so that the code can burn through the test scripts once ready. It may fail for a few times before it starts passing all the test cases. The question is, how do you write the test scripts for a new application that needs to be built (given that we typically talk of automating regression tests with respect to some baseline code which can be assumed to have some state of perfection)? Such test scripts actually may be derived from the first-hand requirements that are written, either in form of BRS or SRS, and should contain both functional and non-functional test scenarios. Then the question is, how would it be foolproof? Note that we are not yet talking of foolproof applications here (it practically does not happen except for real-time life-saving applications that may launch a rocket or operate a surgical robot in a hospital); however, we are talking of continuous releases so that once you feel your current code (satisfying the current requirements) needs to improve, another scrum team would have already, and in parallel, started working on the next release! So, don’t worry.
5. Enable continuous release-readiness. Be prepared to churn out new scrum teams – a part of the current team can start working on the ever-evolving backlog using separate sprints – to work on next releases (see point 4 above).
6. Now comes technology & tools !

Automate infra and environment provisioning – use tools. What kind of code is ‘Infra as code’? Imagine something like –
initiate cloud1 {
RAM 4GB;
HDD 200GB;
create environment1 {
install Windows10 ( );
install Compiler-C++ ( );
install MS-Office10 ( );
}
}
……………. and your developers (or QA) immediately gets the relevant environment they wished for!

Automate tests – use tools. What kind of code is ‘Test as code’? Imagine something like –
test App1 {
/* Comment – each of the functions or methods denoted by XXX ( ) returns a pass or fail */
boolean success[1] = module1.test-login ( );
boolean success[2] = module1.test-billpayment ( );
boolean success[3] = module2.test-printbill ( );
if (any success[] value = fail) { return ‘build has failed’; }
}

Automate develop and build – use tools. What kind of code is ‘Function as code’? Imagine something like –
generate code1 {
if (usecase = login) { generate code-block-login ( ); }
if (usecase = billpay) { generate code-block-billpayment ( ); }
createInterfaces (usecase login, usecase billpay);
}
…………. and also use tools to automatically compile and package the code with other dependent application packs

Automate deployment – use tools. This goes hand in hand with automating infra and environment, given that deployments typically get stuck at infra or environment levels, assuming the build is successful. However, there may be cases where the build is successful (code has worked in developer’s machine), but it fails in target deployment environment (say, for some environment specific variable settings). In such cases, there are alternatives such as putting the code along with its development/test environment directly into the target, as a single container; though we would not discuss it here.

Now your code is in production. However, DevOps is all about getting all of the IT life cycle onto a single seamless chain. So what’s next? Hence, we automate applications and infra getting monitored in production in terms of say, performance and security. If a suspicious event takes place – say, application may show signs of getting into a hanging or breaking state, infra may point to a possible crash due to overload – it immediately and automatically triggers an incident for the service personnel.
Now say, it is Sunday and the personnel is off duty. So the next logical step is to have a self healing system that can, once the event is detected, provision relevant fail-safe mechanisms and enable the system to normally operate. Far-fetched? Nope. This is happening ………….. and I won’t cover here given that it warrants a separate blog 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s