In the past year I have helped scores of developers, testers, architects and ops analyze the quality, performance and scalability problems of the business critical apps for which they are responsible. They shared their data via Share Your PurePath which allowed me to provide them quick feedback on the technical root cause of why an application won’t scale or is slow.

All of these fine people had one thing in common: They looked into the issue when it was almost or already too late. The app was deployed; users started complaining or servers crashed repeatedly.

Don’t let poor quality code and an inappropriate attitude lead to this kind of situation
Don’t let poor quality code and an inappropriate attitude lead to this kind of situation

What I realized is that the technical root cause of these problems can be found in a handful of well-known architectural and implementation patterns: inefficient database access, bad code synchronization implementations, excessive object allocations, wrongly configured frameworks, bloated websites, and ineffective use-case design. In my Share Your PurePath reviews, conference sessions (JavaOne, StarWest, STPCon), and meetup events (Java, .NET, Web Perf, DevOps, Continuous Delivery), I focus on these same problem patterns. They are easy to spot, which is why they should be addressed quickly.

Share Your PurePath Result: We see the same problems repeatedly, and we can stop it!
Share Your PurePath Result: We see the same problems repeatedly, and we can stop it!

The excuse I hear most often is that there was just no time or prioritization for these quality-related items during development. “We will do it later!”, “It’s too much effort right!” or “Isn’t as sexy as building new features” are all common attitudes that will backfire.

Shift Quality Left: I can — and will — help you do it!

Changing your organization and convincing everybody involved in the software delivery process to increase emphasis on quality is something must come from within the organization. And this typically won’t be embraced until after the pains of dealing with quality issues in production – wasting too much time in “war rooms” and “firefights” — has been experienced throughout the organization.

Fortunately, I can remove many of the excuses we too often hear: “We don’t have the tools and those we have are too hard to use!” Thanks to the Dynatrace Executive Management Team who — after listening to convincing arguments from my colleague Reinhard Brandstaedter and myself — agreed to make Dynatrace App Mon & UEM  available free to everyone on the “Left Side” of the continuous delivery pipeline. Here’s the official announcement that was made at the Dynatrace PERFORM 2015 User Conference.

There are also video tutorials posted on YouTube, and multiple blogs, regarding well-known quality, performance and scalability problem patterns.

It is my personal mission to bring you Dynatrace Personal License. After 30 days it becomes "personal".
It is my personal mission to bring you Dynatrace Personal License. After 30 days it becomes “personal”.

What does “free” really mean to Dev, Test & Business?

After you sign up for the Dynatrace App Mon & UEM Free Trial you receive a 30-day trial license enabling you to analyze apps distributed on as many as five different machines, demonstrating the power of Dynatrace PurePath, PureStack & PureLytics. After 30 days the license automatically converts into a Personal License which means that you keep using the full product, with all its features, on applications that run on the same machine/host where you installed the Dynatrace Server.

What I would like to see is developers, testers, architects and even business analysts install Dynatrace on their workstations or test machines to level-up in the following use cases:

  • Developers: While developing, start analyzing how your code executes and interacts with the underlying frameworks. See what happens when you make calls from one service to another. How much data do you really load from the database? How many objects remain on the heap after you execute your new piece of code?
  • Testers: Instead of focusing exclusively on writing tests that validate functionality, go a step further and analyze whether the code is also adhering to the granted “Resource Budget” and basic architectural rules. Ask — and answer questions like: Why execute the same SQL statement five times when we test the login capability? Why does Hibernate/Spring throw 500 Exceptions that never make it to a log file? Why do we make 50 calls to a microservice to display a simple search result page?
  • Architects: Use it for code reviews with your engineers. Look at key architectural metrics, call graphs, memory footprint, and define standards with your engineers based on this data. Use it to determine what this new cool framework is really doing underneath the hood before you promote it as a standard library in your organization.
  • Business Analysts: Validate whether the features and use cases implemented stay within the budgeted running costs, asking: How much data volume do we expect to be served from a CDN, and how much will this cost for the number of expected users; what’s the storage requirement on the database and the cloud provider costs for that amount of data.

Use the Free Trial, Personal License and task list below, to improve your daily work!

Identify Problems before Check-in

Inject the Dynatrace Agent when executing your Unit or Integration Test before checking in your code. Check the PurePath to validate that your code change is not doing anything incorrect like throwing hundreds of exceptions within a new framework that was just added to the list.

Examine the Diagnostics Dashlets in Dynatrace before Checking in Code reveals whether it's safe to commit the code
Examine the Diagnostics Dashlets in Dynatrace before Checking in Code reveals whether it’s safe to commit the code

I recorded several Diagnostics YouTube Tutorials to help you to determine which Dashlets to look at and how to use them. Find all of them here: http://bit.ly/dttutorials.

Sanity Checks Before running Performance Tests

Before executing a multi-user, hour-long JMeter, Load Runner, SilkPerformer, Dynatrace Load, BlazeMeter, SOASTA tests, simply run the scripts for a single virtual user, and do a quick sanity check on the key metrics that will indicate if the load test is going to fail anyway: # of SQL Calls, # of Same SQLs, # of Logs Created, # of Internal Service Calls, Calls to external Services, etc.

It should be fairly easy to read the Transaction Flow and understand a large scale load test isn't needed to break the app (and the DB)
It should be fairly easy to read the Transaction Flow and understand a large scale load test isn’t needed to break the app (and the DB)

Read my blog on Functional Test (R)evolution to see how manual and functional tests can be used to identify performance problems without simulating a heavy load.

Automate & Integrate in your Build Pipeline

Instead of doing all this manually, hook up Dynatrace with the tests you execute as part of your build pipeline. We have great plugins for your Ant & Maven Scripts that automatically inject the Dynatrace Agent and collect data for automated test executions. We have plugins for Jenkins, Bamboo, XebiaLabs and other build-automation software to trigger data capturing, but also pull Dynatrace results into your Build Server Dashboards to avoid going to Dynatrace repeatedly.

Check our GitHub repository and download our plugins for Jenkins, Bamboo, Ant, Maven, and more.
Check our GitHub repository and download our plugins for Jenkins, Bamboo, Ant, Maven, and more.

To get you started there is a tutorial on automating JMeter scripts with Dynatrace and then integrate it with Jenkins.

Help with this mission: Share your stories/PurePaths

You are being offered Dynatrace Personal License. If you take it, I ask only two things from you in return:

  • Send me your PurePaths as I want to learn about more problem patterns. I will share the findings with you and post a blog about how everyone can identify these patterns.
  • Spread the word about “Shift-Left Quality”. Talk to your colleagues and friends. Mention it in Meetups. Please reach out to me if you’d like me to present to your local engineering community. And, if you dare, spread the word by writing your own blog posts or tweet about it!

Your first step should be to Get Your Dynatrace Free Trial which will automatically convert into a Personal License after 30-days. Check your email and spam folder for emails from me — Andi Grabner — as it has been reported that  some emails sent out during the free-trial period are detected as spam.