Ad
More Related Content
What's hot (20)
Similar to Preparing for DevOps (20)
Ad
Recently uploaded (20)
Ad
Preparing for DevOps
- 1. Preparing for DevOps GROUND WORK EKLOVE MOHAN
- 2. DevOps Introduction • A combination of "development" (and QA) along with "Operations". • DevOps emphasis on developing a culture within the organization for the transformation. • To build the culture, first step is to build maturity among developers and operations. • DevOps cannot be implemented by any organization overnight or even in a fortnight. It requires a lot of groundwork, dedication, and in some cases enforcement as well.
- 3. Crawl-Walk-Run-Fly Crawl • Standardize Source Control • Define branching strategy • Define Defect Tracking tool • Automate System test cases • Plan for Synthetic Transactions • Enable Quality Checks • Enable Automated Unit Test cases • Expose to cloud • Build Knowledge base Walk • Build Continuous Integration pipeline • Build an Artifact repository • Build Continuous Delivery pipeline for Dev • Enable Synthetic transaction Run • Build Continuous Delivery pipeline for QA and production • Enable Build Promotion • Setup Infrastructure and application monitoring tools Fly • Enable Blue Green environments • Enable Infrastructure as code • Enable Metric based alerts • Enable Continuous Deployment • Build pipelines of pipelines • Progress towards DevSecOps
- 4. Crawl Stage - Roles and Responsibilities • Organization • Form a group of thought leaders (Project Managers, Architects and Product owners). • Source Control Standardization • Define branching strategy • Define defect tracking tools • Monitor progress on a daily basis • Quality Assurance (QA) • Implement system test cases automation • Plan for Synthetic Transactions • Developers • Enable Quality checks • Automated unit testing • Exposure to cloud • Operations • Understand the product • Enable configuration management tool • Exposure to cloud • Monitor the infrastructure and application
- 5. Form a Centre of Excellence CTO Project Managers Architects Product Managers Transformation Head • Identify a group of Project managers, architects and product managers who can run this CoE. • Generally, this group is termed as “DevOps CoE”. As of now, call it “Transformation CoE” since the focus is on transforming the organization to be able to adopt DevOps one day. • Group focuses on standardization of tools and processes across all the projects within the organization than for a single project. • Work on Continuous Improvement through feedbacks and retrospections at regular intervals.
- 6. Standardize Source Control • Identify a list of all the source control management tools that are being used in the organization. • Filter to one. Compare features of all the source controls (cost, on-prem vs cloud etc) or pick the one that is common across most projects (may not be the best choice). • For each project to be migrated, identify whether we need all the history or can live with, say 6 months of history. • Use Git command to clone from original source control along with history. E.g. if original source control is TFS, use • Don’t discontinue the original source control as yet. Create a sync job between the old and new source control system. Developers continue to checkin/commit to old but the sync job moves the updated code into new. No one directly commits into new. • Plan training for developers and operations on the new source control system. git tfs -d quick-clone --changeset=567716 <tfsUrl> “<folder to clone>" "C:/B1“ git tfs pull
- 7. Branching Strategy • Use a standard branching strategy. Big no to long running branches. • Pick between “Single Trunk” or “Feature based” branches. • “Single Trunk” has no or minimum merge conflicts, since we develop of the same “trunk” and branch only when a release is required. Hotfixes are also developed on trunk and then “cherry – picked” into release branch. • “Feature based” – create a code branch for each feature. Merge from trunk to “feature” branch on a regular basis to avoid merge conflicts later. Feature branch are short lived branches and should be merged back into the trunk as soon as the feature is complete.
- 8. Defect Tracking Tool • Similar to Source Control systems that may exist in plenty within the organization, compare all the tools but filter to one. • Most of the modern tools have similar features therefore compare based on on-premise vs cloud, cost, testing team comfort, reporting capabilities etc. • The tracking tool should have provision of integrating with the Continuous Integration tools. We would need that when we start the DevOps process. • Define training plan for the entire team on effective usage of the tool.
- 9. System Test case Automation • Move towards automated test cases. Manual Test cases may have greater test coverage but is not automated and are time consuming. • Target coverage percentage (Functional coverage) for each sprint. • Start with converting regression test cases to automated. New feature development continue to be manual. • Run the automated test cases on a daily basis (run it nightly every day once the test case suite is stable). • Develop competencies on Behaviour Driven Development (BDD) and then opt for tools like Cucumber.
- 10. Plan for Synthetic Transactions • A system consist of multiple applications. Each application may run on its own set of servers. Each may work as an individual unit but validating that they are working as a group is important. • Generally the first request coming on these servers may timeout or fail due to warm up or network error. Synthetic transaction provides early feedback if any of these issues exist, even before even the business starts. • Consider Synthetic transaction as a void submission to the system that will create dummy records in the database, initiate a transaction, hit the third parties, store the updated values and then perform a clean up of the entire dummy transaction. • Identify one most critical scenario based on the business needs. This transaction should ideally touch all the discrete systems for that application. • This will not be used right now in the “crawl” stage, but is going to be used when we start “running”. Plan for Synthetic transaction now and build during the “walk” stage.
- 11. Enable Quality Checks in the code • Write code that follows industry standards best practices. Every programming language has defined guidelines that the developers should follow. • Manual code review are too dependant on the individuals. Bring in automation. E.g. enable FxCop for .NET, PMD for Java etc. on each developer machine. • Use a centralized tools or platform that can show quality scores and deduce code quality on the basis of design, architecture and test quality for the project. • Compete with your project and not with others. The quality score of today should either be the same or improve tomorrow but should not deteriorate. • Consider code quality issues same as functional issues and fix them on priority.
- 12. Implement Automated Unit Test Cases • Build sense of responsibility. The code developer writes, first needs to be tested by the developer. • Write automated unit test cases. For legacy applications, don’t worry about Test Driven Development (TDD) as yet but do understand the concept. • Refactor the code to loose couple. Use Interfaces or abstract classes to inject the dependencies. • Monitor the unit test code coverage. Define goals for each sprint. Be cognizant of the fact that the coverage will be higher when you start writing the automated test cases, but it will stabilize and difficult to increase after a point of time. • Ensure that there is atleast one assertion for each test case. Don’t write test cases for the sake of coverage. Ensure that the test cases do fail when code is updated and the testcase is not.
- 13. Exposure to Cloud • Consider cloud as a catalyst to DevOps. At some point of time in your organization, they will go hand-in-hand. • Developers are responsible for coding new features and are generally not aware about deployments or about basic networking concepts like subnets, ports, private and public IPs, load balancers etc. DevOps require developers to know all this. • Learn by reading the books/watching tutorials or by doing the things practically on cloud. Learning curve is much shorter when done practically. • Get a sense of building and deploying the code on cloud. Observe each settings. Understand securing the instances. Play with servers, create and destroy at will. • For Operations, move to cloud and understand the shared responsibility model. Do look at serverless. Change mindset from procurement to on-demand services. • Build atleast one non production environment in collaboration with the development team on cloud.
- 14. Understand the Product • Operations, confined to deployment and monitoring of the infrastructure. With DevOps in mind, it is important to build understanding of the application you are building and supporting. • Operations to be part of the daily scrum meetings to understand what is coming up in near future. • Collaborate with developers to understand the changes in the functionality. Do raise concerns if you think something can create issue when deployed to production. E.g. increasing the application log volume on the file server due to change in verbose level etc • Special attention to all third party integration. Ports, security credentials, certificates and the protocol used to send and receive the information is critical. • Analyse configuration management tools like puppet or Chef. This will be the next level of automation that we would target so start preparing. Knowing about the product would greatly help in preparing the scripts. • Going for IaaS, PaaS or SaaS would be easier to determine since operations not only knows about the server configuration but also about the application needs.
- 15. Monitor Infrastructure and application • Monitor not only Infrastructure but applications as well. Change mindset to not only look at CPU utilization, memory utilization, disk space, I/O writes etc but also at application component interaction. • Evaluate tools which run both on on-premise as well as cloud even if you don’t have any plan for cloud. Some day you will move to cloud, so be prepared. • Get away from custom dashboard tools build by your team few years back. They wont work on cloud. • Build skills on Infrastructure automation. Practise on cloud.
- 16. Closing words • There are four stages of maturity defined in this deck (Crawl, walk, run and fly) but only “Crawl” has been detailed out. • Let the “Crawl” phase run for 2-3 months. Gather feedback, conduct retrospection. Identify the challenges and work towards remediation. • Move to the “Walk” stage. Don’t go for a big bang approach. Start the stage only for 2-3 projects and monitor the progress.
- 17. Coming up next Details on how to work during the “Walk” stage.
- 18. Thank you