DevOps at Lean Apps
•Descargar como PPTX, PDF•
3 recomendaciones•405 vistas
Understand what is DevOps and why is it important for an organization. See the different benefits of continuous Intergration and continuous Deployment. Also see how Lean Apps implements DevOps today
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a DevOps at Lean Apps
Similar a DevOps at Lean Apps (20)
Último
Último (20)
DevOps at Lean Apps
- 1. DevOps What ? Why ? Who ? How ?
- 2. What is DevOps ? DevOps is the culture of Development and Operations Engineers, participating together in the entire service lifecycle, from design through the development process to production support. DevOps is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operation professionals.
- 3. What actually is it ? DevOps is the umbrella term for the practice which encompasses - ➔ Culture Cross-Team collaboration. ➔ Automation Automating repetitive tasks. ➔ Monitoring Monitoring systems, apps, etc. ➔ Sharing Sharing reports, issues, regarding code, system, application, etc.
- 5. DevOps Process Flow at Lean Apps
- 8. CSS LINT Unit Testing Code Quality Check Notifications Archive
- 9. Unit Testing Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. ➔ Benefits ◆ Unit testing increases confidence in changing/ maintaining code. ◆ Easy to catch any defects introduced due to the change
- 10. Code Quality Check Code Quality Check helps us deliver higher quality software and fix critical security issues in our applications. ➔ Benefits ◆ Quantifies the quality of your code. ◆ Metrics that tell useful things about source code. ◆ Trace through the code paths and quickly find subtle bugs that would take a human forever to track down. CSS Lint
- 11. Notifications Notifications play a major role in the DevOps process flow. Notifying the developers/QA/Scrum Masters about builds, code quality and deployments is very crucial. ➔ Benefits ◆ Build and Code quality reports are sent via notifications. ◆ Stakeholders know the quality and efforts in development. ◆ QA know when a new build arrives.
- 12. Artifacts Generating artifacts for deployment ends the Integration cycle. ➔ Benefits ◆ Generates a ready-to-deploy object in the form of : ● WAR (Java Projects) ● ZIP(PHP Projects) ● APK(Android Projects) ● IPA(iOS Projects).
- 15. Benefits and Power of DevOps 1. Agility 2. Velocity - Faster Delivery 3. Continuously incorporating Feedbacks. 4. Visibility to Build, Run and Secure Modern Applications 5. Innovation 6. Software Stability and Quality 7. More time to innovate (rather than fix/maintain). 8. Team Empowerment/Communication/Collaboration. 9. Increased Effectiveness. 10. Customers/Clients/Employers love DevOps. 11. Zero blame shifting, and more of owning of responsibility.
- 16. Collaboration ➔Collaboration is the most important part of DevOps. ➔Dev and Ops work best when they work in a collaborative manner as defined by DevOps. ➔It is the key to success.
- 18. What people are saying ?
- 21. What Lean Apps people are saying Build flavours in Android generate environment specific builds efficiently in Jenkins. Another benefit is learning about DevOps & automation. Saurabh Sircar, Full Stack Mobile Dev Saved us a lot of time with automation, and build reports make it very easy for us to locate errors, if any. And learning is the best part. Prajwal Thakre, Java Dev Code validation from Unit Tests gives us a sense of confidence about our code, and metric reports show us the exact quality of our code. Chandrakant S., Java Dev Automated notifications about Builds is one of the best things for me. Apart from this, a lot of time is saved from Dev’s end as well as QA’s. Niraj Gahukar, QA
- 22. BY: Yash Shanker DevOps at Lean Apps QUESTIONS ?
Notas del editor
- A unit is the smallest testable part of software. Testing each unit with mock inputs is Unit Testing. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person.
- A unit is the smallest testable part of software. Testing each unit with mock inputs is Unit Testing. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person.
- A unit is the smallest testable part of software. Testing each unit with mock inputs is Unit Testing. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person.
- A unit is the smallest testable part of software. Testing each unit with mock inputs is Unit Testing. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned. Codes are more reliable. Why? I think there is no need to explain this to a sane person.
- strategic imperative becomes responding rapidly via agility and modularity through DevOps and adaptive IT. When you don't know what the future holds, it's important to have the infrastructure in place that can respond to business needs on the fly. Speed to market and quick iteration is critical in competing in software, otherwise competitors will outpace your product development and win the market. To compete, engineering teams should adopt DevOps to enable teams and break down friction in order to increase agility and speed to market. Surveys have shown that organizations successfully implementing DevOps tools and practices are likely to experience high growth in profitability, market share, and productivity goals
- Author of NextGenDevops ...
- Co-Founder DevOpsGuys and MS Regional Director