Release 7.0 and The Vision

I would like to officially welcome you to 2016 autumn/fall (depending where you are). The days are getting shorter and the weather is becoming more moody. Fortunately, there are even good and exciting news. The number 7 in the PerfCake version number is not only lucky. It also introduces 57 total enhancements and 17 bug fixes. We spent extraordinary efforts on bringing the best performance testing tool we could to you. Feel free to download now!

Except for code enhancements, we also completed our guides (Users' Guide and Developers' Guide) to carry the best up-to-date information. In addition to this, we realized that, first, performance testing is not an easy job and there aren't too many resources on how to do that properly, and second, some scenarios in PerfCake that can be especially powerful aren't very obvious on first sight. To overcome these difficulties, we started writing two books on LeanPub. First is Performance Engineering and the second is PerfCake: Performance Testing Scenarios. The first one will ask you to contribute a small amount of money to support our work, the second one is and will be for free forever, however, small contributions will be gratefully appreciated.

I would like to use this opportunity to also introduce you to our vision of future of performance testing and what we do to make it happen. For a long time, we know that we suffered in the area of development of performance test scenarios for PerfCake. No matter how powerful the XML is, we need something more visually appealing. Currently, an IDE plugin is under development that will bring you not just a scenario editor but also a debugging tool. You will be able to use the new debugging facility in PerfCake and monitor an actual test execution.

Regarding runtime, we would like to work more in a way of performance testing as a service. Users could use a Web UI to connect their favorite cloud environment (e.g. EC2, Azul, GCE, OpenStack...) and use the machines in the cloud as agents to run the performance scenario in a cluster determining geographical locations and other attributes.

The results would be then stored in a PerfRepo which is already a part of our portfolio. The PerfRepo is undergoing a rework to cover more common use cases in fewer clicks and be more user friendly. Also the integration between PerfCake and PerfRepo will be more seamless and automated. The results will be stored for later examination, comparison between various runs, and reporting. Again as part of our Web UI suite.

Regarding the PerfCake core, we are not aiming at any "shake the world" changes for spring release. Unless there is any demand on specific features, we will cover the issues currently open on Github and concentrate more on the books, documentation, video blogs and viral marketing in general. The development efforts will be spent more on the supporting tooling.

Just for curiosity, the code name of this release is Raspberry Moon according to a full moon we had a chance to see while thinking about the code name. It was a beautiful full moon low on the horizon and it had a nice red-pink (like raspberries) color.

University release 4.1

We have been invited to teach a lecture on performance testing at Faculty of Informatics, Masaryk University. The choice of the performance testing tool to use during the practical part was clear (PerfCake if it wasn't obvious). We already knew about a couple of things that were broken in 4.0. So for the demo to be as smooth as possible we have decided to create a dedicated University release, numbered 4.1.
It has five bug fixes, three enhancements and we also updated our web pages. All our friends and users are strongly recommended to update to version 4.1 to avoid any possible inconveniences.
Did the lecture went all that smooth in the end? Of course not. What was the deal breaker? The students were supposed to run PerfCake on a commercial operating system by Microsoft. This has not been tested thoroughly by us. We found out that the main script in the binary release works only when executed from the main installation directory. Plus some more minor things that we were able to overcome. Some of them are already fixed in the devel branch but we are unlikely to create another release now. Possibly later in the summer as we are still hoping to be able to show PerfCake in public again.

From 4.0 to 4.1

As usually, we celebrated spring equinox with an even numbered release of PerfCake. We managed to release a couple of days earlier. The main reason for that was that we had a planned vacation for the release period.
This release has some really cool features that makes PerfCake even easier for usage. Actually there are 26 of enhancements and new features in this release. Just have a look on the list to see if you could make a use of them.
Except for these cool features there is one thing we are especially proud of in this release. This is its stability. We finally managed to get rid of all the raise conditions appearing now and then and bothering us constantly. I do not want to claim that there aren't any now. But there aren't any we are aware of. And there is a fair chance that nobody will discover a new one (until we change the code ;-)).
Unfortunately, bad things happen and there will be version 4.1 soon. Especially due to a bug that prevents smooth shell script usage randomly.
We also decided to fix several other issues. This is mainly because we want to get ready for a possibility to present PerfCake publicly soon again. All information on that will be shared once we have an official confirmation. Stay tuned!

Technical preview of DSL is in 3.3

As we promised, PerfCake 3.3 is out. The main reason for this release is a feature we originally planned for 3.0. We wanted to present this at GeeCON 2014 in Prague, so here is the first "technical preview". We also fixed some minor bugs - as we found them, there was no reason for postponing the fix. We hope to collect some feedback on the DSL implementation and possibly improve it.

We also look forward to see current and find some new users at GeeCON. Meanwhile, we also presented PerfCake in an IT company and discovered some new feature requests. Therefore, we started speaking about receivers, timers, correlators... You might possibly see some of the revolutionary concepts in release 4.0.

PerfCake 3.0 is out, so is 3.1 and 3.2...

For us, Release 3.0 is a major achievement and a significant success. We managed to fix multiple kids' diseases that were hidden in the code, we reworked problematic parts, automated many steps, revised the whole project infrastructure including CI, web site, release procedure... Especially the later one still needs some tweaking as explained later.
You can have a look on the list of closed issues for this release. The user experience should be now better. We prepared automated scenario migration to the last version (running this is however still little bit clumsy), we fixed all the issues with reporting (early or late results were not recorded), we did some PoC with Google charts output (and decided to solve that differently in version 4.0), we have some progress on the tooling (Eclipse plugin is almost done), we extended our tests to the level of advanced integration testing (running in-container testing of JMS sender for instance, special credit goes to an university student who implemented it), and many other changes that might be hardly visible from the outside but were important inside.
There is still one component in PerfCake that is not easy to extend or to implement on your own - the generators. They do not have an interface but an abstract parent class. This is something we would like to change for programmers' convenience.
From the users perspective, our priority is the tooling, documentation, migration from previous versions (and possibly migration from other tools), execution in a clustered environment, ability to directly represent results graphically (using charts).
We also have a plan to finally provide another way to specify the scenario - a DSL language. This feature is almost in a technical preview state.
So, what went wrong during the release and why we ended up with version 3.2? The reason is quite silly and it is a lesson learned for the next release. During the release procedure, we prepare everything on Github first. The master branch has a new version and the devel branch is set to continue on the next release. Then we prepare the artifacts and upload them to Sonatype for them to appear in the public Maven repository. Then our Continuous Integration environment automatically consumes the sources from master and runs all the tests. It also creates downloadable artifacts for automatic web pages refresh.
So after releasing version 3.0, we realized that the tests do not work well in the CI environment. We decided this must be caused by a different environment setup, implemented a fix, executed tests locally and released version 3.1.
But this did not help! Still the same errors appeared in the CI. After a more thorough inspection we realized that there is a problem with the javadoc Maven plugin (the recent version was backward incompatible). So we eventually fixed that and released version 3.2.
Next time, we must run our CI stuff before the upload to Sonatype.
And one more thing - there will be another release, version 3.3, shortly before GeeCON in Prague 2014. We want to present some cool new features there during the Lightning talks.

Release 2.1

The summer season is aproaching and we are half way on our journey to the next release of PerfCake that will be unleashed in Autumn. We are working hard to make PerfCake the #1 performance testing tool by adding new features, refactoring and optimizing the features that are already there and fixing bugs that eluded us and made it to the previous releases.

During midsummer we released hot-fix release v2.1 that fixes one such bug.

We would like to thank everybody who have helped... Thank you very much!

Release 2.0

Some time ago, we celebrated the Spring equinox with the 2nd release of PerfCake. Did we manage to implement everything we wanted? The answer is no again. Does it really matter? Not that much. We mainly focused on fixing some issues that the users were facing. Especially correct reporting of reaching 100% in time controlled runs. We also improved the framework performance so it has minimal influence on the system being measured. So the priorities have changed and we did some things that were not in the plan originally. It is a very nice feeling to see how the product gets matured. Like some good quality whisky...

Since release 1.0, we presented PerfCake to local public and we were surprised by the positive audience feedback. However, there are still questions we are not able to answer at the moment. Or more precisely, we are not able to provide the evidence for our answers. So before the next release, we would like to aim on being the best performance testing framework on the market. Because of that, we plan to publish comparisons with other frameworks and provide migration scenarios.

We learned that nice reporting is important to our users. So we would like to implement a reporter that generates charts.

For links to public talks, see our twitter.

Release One

So here we are. Our first release is out. For us, this was the first grown-up money-less open-source project we pushed so far. You know, sometimes you have a great idea but the lust goes away too soon. I do not know what makes PerfCake so different that it worked out. But I am really glad we made it. We learnt a lot, everybody played every role at least for a while (as there are more roles than available actors). And here we are!

Did we manage to achieve everything we wanted? Definitely not. Release 1.0 is not perfect. But we tried hard and we are almost there. The documentation needs more time to settle down, validation must be re-done, there is a design flaw in reporting the 100% status message for time based message generation... Are these just the details or major issues? This is what the users must tell us now.

At this point, I would like to thank to everybody who helped on the project. Not only developers and contributors, but those who reported or just found bugs, sent pull requests, provided their technical advice, motivated us to go on... Thank you very much!

Now, this is not the end. This is just the beginning and we must refresh our minds and head towards the second release, the Spring Edition!

Let's spend the winter writing some good piece of code. Onwards!