[S1-A&D] Practicing DevOps towards Automation

DevOps means Development + Operation. DevOps has now become DevSecOps with additional focus on "Security". DevSecOps does not bring much difference to DevOps aspirants rather this increases the earlier boundary. In this article, I will use "DevOps" & "DevSecOps" interchangeably. I will try to explain followings

• Pre-DevOps and Post-DevOps situations
• Automating processes through DevOps practicing

Myth about "DevOps", many people think that "DevOps" reduces the IT cost to half or operation cost is removed, because no-one is developer or operation support guy. Recently I was doing a proposal including DevSecOps practices for reputed mobile-operator in APAC region. During negotiation, we learned that customer expects half of the resources as proposed, because when there is one team instead of two teams for Delivery and Operation. We had tough but healthy discussions to convince what DevOps brings to a customer. Actually DevOps brings optimization and efficiency, but does not reduce the work usually done by operation team. Rather that work comes to delivery team and operation work has to be ensured by them by adding helping hands to them, because the delivery team is already occupied in their development work that any additional work will lead to low quality delivery. In that context, I thought to write this article with real experience to clarify DevOps use in real life.

Pre-DevOps experiences, Before jumping deep into "DevOps", let me make you situation before "DevOps". In "Pre-DevOps" environment, there are mainly delivery and operation teams. IT assignments related to software development can be categorized as follows

• Transformation Project for product change, technology change, or modernizing current implementation
• Managed Services with or without "Application Development for CR (Change Request)"
• Only "Application Development" work

In all above scenarios, delivery team completes “IT assignment” as per agreed plan and hands-over to operation team. In “Pre-DevOps environment”, hands-off means “Throwing it over the wall” and after hands-off & warranty period delivery team is either dissolved or retained in form of AD team, in both cases operation team is orphan and disconnected with delivery team. Such modality of working between operation & delivery teams had several issues like

1. Any small development, customer is dependent on delivery team, which causes delayed TTM
2. Any configuration level changes also operation team sometimes, is dependent on delivery team
3. Operation team owns the customer business, but they hide themselves behind delivery team to safe-gaurd against any failure.
4. Both teams works in pre-defined boundary, which stops bringing synergys for each other. 

Let’s understand usual practice followed by operation and delivery teamsScenario

So you can find several drawbacks of “Pre-DevOps working style”, which draws the attention of IT practitioners to improve these working process to give more benefits to business and higher ROI (in terms of TCO & TTM). 

Post-DevOps expectations, So we understand that there is justified role as L1, L2 and L3 levels, but DevOps brings concept of “one DevOps team” what it does

1. Delivery team (allocated DevOps team) is part of one team and is more close to production without any WALL, to be on top of any production issue
2. Operation team (allocated DevOps team) is part of one team, who have seen and experienced the complete delivery “specific IT assignment”, so no hands-off required as earlier

Now we understand the objective of “DevOps”, in order to practice “DevOps”, “IT Service Providers” must have smart & automated methods to perform any activity of “Pre-DevOps regime”. With “DevOps practice” 

1. L2 team (Operation team in Pre-DevOps) and L3 team (Delivery team in Pre-DevOps) will become part of “One DevOps Team”
2. L1 team (Operation in Pre-DevOps)
3. a) will still remain dedicated for monitoring and (Operation team in Post-DevOps)
4. b) L1 team will continue to shrink based on process converted as automated i.e. using BOTs or Automated job can monitor system and raise automated SR for further analysis and debugging.
5. Further “One DevOps Team” will have more automated processes to apply “Proactive Corrective Action”
6. So “IT Service Providers” must focus on automated process and BOTs, to practice DevOps and generate profit margins, else on the name of “DevOps”, “IT Service Providers” can have “One DevOps Team” but they cannot save money with reducing human resources at L1 & L2 level.

Automating processes starting from demand request till GO-LIVE to managed service, is an important aspect of practicing “True DevOps”. Let me share some thought processes, what and how we can achieve.

Let’s write an application named “DevOps Management System - DMS” which will help to automate complete “Application Development Life Cycle - ADLC”, let’s exercise ADLC and understand the use of DMS.

1. Assuming “Customer and IT Service Providers” have development engagement in agile mode.
2. Business team, User experience and Defects are different sources of new demands.
3. We will call all these demands as demand stories and captured into DMS.
4. These demand stories will become part of “Product Backlog” at JIRA via automated API integration.
5. Based on business priority, one or more E2E stories will be clubbed into one CR or Project. DMS will initiate “Assignment” of type CR/Project.
6. Consolidated solution approach of Assignment, will be prepared offline by solution team and will be uploaded into DMS along with impacted application.
7. On upload or change of “Consolidated solution approach of Assignment”, review notification will be sent to the respective stakeholders.
8. Notified stakeholders will review and share solution acceptance in DMS. 
9. On solution acceptance, “Development Head inside One DevOps Team” will be notified via DMS.
10. “Development Head” will review, acknowledge and accept solution for implementation in DMS. “Development Head” will also allocate resources against impacted application.
11. On acceptance by “Development Head”
12. a) Sprint will be created by DMS in JIRA
13. b) Respective application code branch will be created in GITLAB (You should plan clean branch strategy for Ongoing Development, Final Development, Pre-Prod, Production)
14. c) Allocated team members will be notified along with “GIT URL” in notification
15. d) So there one dedicated branch per sprint per assignment.
16. Developer will do “GIT CLONE” and keep commit new code on a daily basis into “Ongoing Development” along with proper comment. Note : COMMIT time comment will be auto generated along with custom comment as suffix by developer
17. Developer will do “GIT MERGE” code from “Ongoing Development” to “Final Development” branch and DMS will keep should ongoing progress of respective assignment.
18. On successful code merge, JENKINS Auto Build will be triggered using server side maven utility. 
19. a) CODE-QUALITY check will be performed automatically in CI pipeline at JENKINS
20. b) PATCH vulnerability check will be performed automatically in CI pipeline at JENKINS
21. c) Many other checks will be part of CI pipeline. Note : In the generated build, all committed comments will be collated and associated with target build, so that build summary is not lost in this automation.
22. Cutting long story short, every step under development life cycle will automated via DMS
23. Generated build shall be deployed automatically on respective target environment e.g. “Testing”, “Pre-prod” and “Prod”
24. “Automatic Deployment” shall be based on “Test Result Acceptance Criteria”, if falls in agreed limit rule configured in CD pipeline.
25. RPA based automated UI flow testing, to execute regression test faster.
26. Multi-server deployments need to be automated and hassle free.

Automating Story Management

Automating CI/CD process while process execution

Conclusion,

Right selection of tools and robust CI/CD pipeline ensures proper use of “DevOps Practices”, otherwise “Improperly implement DevOps” can become a liability to “IT Service Provider”.

If you are looking for any discussion please drop me mail or give me a call on contacts mentioned in linkedin.

About author

Profile : Rajesh Verma - Brief profile

Source : link for this article here

Series : S1 (Architecture & design)

Episode : S1E1 ([S1-A&D] Practicing DevOps towards Automation)

Author’s approach : Rajesh wants to share his learning & experience gained throughout his career from various sources. Author started the series on architectural topics and this article is one of the episodes in that attempt. Author feels that lots of information is available on various forums, but scattered here & there. Episodes in this series will be designed for most of the relevant topics in architecture-&-design, published gradually and organized in logical sequence. Principally episodes will have linkage with other episodes, so that readers can have proper connection among the topics and would be able to correlate with ongoing activities in their software life. Topics for example will be related to functional architecture, integration architecture, deployment architecture, microscopic view of mostly architecture-building-blocks (ABBs), security guidelines & approach to comply, performance KPIs & engineering, git branch & DevOps enabled automation strategy, NFR aspects (e.g. scalability, high-availability, stability, resiliency, etc.), commonly used architecture styles & design patterns, cloudification approaches, multi-tenancy approach, data migration, channel-cutover & rollout strategy, process standardization & simplification, greenfield rollout & brownfield transformation journeys, etc.

Thank you for reading the post, please stay connected.