Tech Notes

DevOps is neither a tool nor a methodology.  It is a philosophy for how people in the software development supply chain interact.  DevOps practices include processes and tools that streamline software delivery by continuously improving feedback from production development and automating delivery activities. Tools required for streamlining the delivery Tools to automate and manage builds Tools to automate testing and results reporting Tools to provision environments (physical, virtual, private and cloud) Tools to orchestrate continuous delivery of applications Common Tools Source Control (Git, Subversion, CVS etc.) Build Automation (Ant, Anthill, Maven, Make etc.) CI Tools (Jenkins, CruiseControl, Bamboo, TeamCity etc.) Test Tools – Static Analysis Java Stack (Checkstyle, PMD, FindBugs, JDepend etc.) .NET Stack (Stylecop, SourceMonitor, CloneDetective, NDepend etc.) Ruby Stack (rubocop, Rails best practices, Cane, Reek etc.) Test Tools – Unit Tests (JUnit, TestNG, NUnit

Sprint becomes a mini-waterfall and testers are involved late in the sprint Lack of focused testing as for many other things testers time is required like prepare stories for future sprints, keep an eye on broken build on CI, work with product owner for demo, help developers with test data, environment setup etc. Complexity of test environment especially when quick fix need to be tested before deploying to the production Need to learn on continuous basis especially new tools & technologies Due to frequent requirement changes, ensuring full test coverage is not straight forward Support of testing for daily or semi builds Lack of documentation Code accidently broken due to frequent builds, which results loss in testing time Support testing for the last minute changes especially with the deadline approaching Test team gets squeezed due to over commitment and sprint durations

·          Start small at the beginning of the project and build the test suite iteratively with each passing sprint. ·          Create a test automation backlog to serve as a prioritized list of automation tasks. This will help you stay focused on the immediate tasks without losing sight of the long-term goals. Have a good look at the available testing tools and their capabilities and don’t be afraid to invest a sprint or two in getting your hands dirty with them. This will ensure that you get started with the best available testing options and establish a realistic assessment of their features. ·          Keeping your tests and data loosely bound will help you to switch testing tools with ease in the future if such a need arises. ·          Create meaningful tests and give due consideration to concerns like maintainability and execution time while adding tests to the automation suite. ·          As soon as possible, make every effort to enable the whole team to use the secu

·          Opening/Creating different types of account viz. Saving and Checking (CASA) and Loan Accounts Etc ·          Cash/ Cheque Deposits using different services at Branch by Teller, and Cash Deposit Machines for (Self / Third Party) ·          Cash Withdrawal, Deposits, Transfers(between linked accounts) from ATM terminals ·          Low-volume (NEFT) and High-volume (Real time gross settlement systems - RTGS) transactions using different Banking channels (Like Internet Banking, Mobile, IVR Etc) ·          Automated Clearing House (ACH) and Electronic Funds Transfer (EFT) payments ·          Cash/ Liquidity Management function ·          Stop Cheque request, Utility Bill payments, Credit card Bill Payments Etc ·          G/L (General Ledger) postings happening correctly/not for Book keeping and Accounting entries ·          PIN Change, statement request (Mini statement, and Historical statements) ·          Time Deposits and Recurring Deposits and Loan proce

Code Deadlock "By drilling into each Code Deadlock event, operations were able to analyze the various thread contentions and locate the root cause of the issue. The root cause of the slowdown turned out to be an application cache which wasn’t thread-safe. If you look at the screenshot below, showing the final execution of the threads in deadlock accessing the cache, you can see that one thread was trying to remove an item, another was trying to get an item, and the last thread was trying to put an item. 3 threads were trying to do a put, get and remove at the same time! This caused a deadlock to occur on cache access, thus causing the related JVM to hang until those threads were released via a restart." Code Deadlock Waiting Threads “I simply take the CPU Time and the Method Execution Time of a particular method, component or framework. Here is an explanation of these two values: §   CPU Time: Is the time spent on the CPU by the executed code §   Execution Time

Stop the   world   (STW) garbage collection "The only remaining problem with the latest result above is the long Old generation (Full) GC pauses of about 8 seconds on average. These pauses have been made rare by proper generation tuning but when they occur they still are a nuisance to users because during their duration the JVM is not executing worker threads (stop-the-world GC). In our case, these 8 seconds are caused by an old and slow test server and could be up to a factor of 3 faster on modern hardware. On the other hand, today’s applications typically also use larger heaps than 1 GB and have larger amounts of live objects in the heap than in this example. Web applications nowadays work with heaps up to 64 GB and (at least temporarily) need half of that for their live objects. In such cases, 8 seconds is short for Old generation pauses. They can easily come close to one minute which is totally unacceptable for an interactive web application" Tuning Garbage Collec

Most online applications of scale are backed by some form of relational or non-relational database and it can be easily said that backbone of any modern web application is its data.  As a result, the database is critical to the functionality and performance of the application and should not come as a surprise that it is the biggest source of performance issues for web applications.  The problems can occur at many places, the application code might be accessing the database inefficiently, database connection issues or database itself might need tuning.  In this blog, I will be focusing mainly on database performance issues that can occur on application server (business logic) side.  The web application can be JAVA based, PHP based or ASP.NET based but the core of the issue would be same. Application code making excessive database queries This performance anti pattern ultimately results in slow response time as application load increases.  The problem is hard to detect under low