Archive for the ‘Devops’ Category

Do You Hear That? It’s the sound of Keyboards! Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Our brains are on fire, our keyboards are hot, and the joke in the office the past few days has been over our extreme excitement for the eventual need to buy sunscreen since our Boston winter leaves us Vitamin D deprived. Why is this the case, you may or may not be asking? Well, I plan on telling you anyway because it is just too exciting not to share!

Our team is preparing for CLOUD FOUNDRY SUMMIT SILICON VALLEY! We felt a social duty to let all of those we care about and want to be there with us for what’s sure to be the summit of the summer (how can it not be when it is being held in June in Santa Clara?!), that the last call for papers is quickly approaching (no seriously, it’s this Friday, February 17th).

Just as a refresher for those on the fence, Cloud Foundry Summit is the premier event for enterprise app developers. This year the Foundation, through market research and feedback, found that interest and industry need is engrained in the focus on innovation and the streamlining of development pipelines. For this reason, Summit 2017 is majorly honing in on microservices and continuous delivery in developers’ language and framework of choice. That is why the session tracks available will be Use Cases, Core Project Updates, Experiments, Extension Projects, and Cloud Native Java. Each session that is chosen for the conference is enabled (1) primary speaker and (1) co-speaker. The primary speaker receives a complimentary conference pass while the co-speaker receives a discounted conference pass. So what’s stopping us from getting involved? Absolutely NOTHING!

As a sneak peak to a few of the topics our team have submitted for approval, see below:

  • Adopting DevOps and Building a Cloud Foundry Dojo (Lessons Learned)
  • Lift & Shift Your Legacy Apps to Cloud Foundry
  • How to Develop Scalable Cloud Native Application with Cloud Foundry
  • Enabling GPU-as-a-Service in Cloud Foundry
  • Blockchain as a Service
  • Avoiding pitfalls while migrating BOSH deployments
  • Spring Content: Cloud-Native Content Services for Spring

 

So, now what’s stopping YOU from getting involved? Submit papers here: https://www.cloudfoundry.org/cfp-2017/ and/or register here: https://www.regonline.com/registration/Checkin.aspx?EventID=1908081&utm_source=flash&utm_campaign=summit_2017_sv&utm_medium=landing&utm_term=cloud%20foundry%20summit&_ga=1.199163247.1732851993.1460056335

Last but definitely not least, let us know if you plan on coming—we are more than happy to share sunscreen 🙂 We cannot wait to see you there!

Dell EMC Dojo at Hopkinton! Reviewing what we covered, and what we learned

Reviewing what we covered, and what we learned

Hey again everyone! We’re writing out today to talk about a few topics that we covered during our time at the Dell EMC Dojo Days in Hopkinton. We met with a lot of great minds and took plenty of input into how we work. We also gave a lot of insight to passersby in what we did and how we worked.

Firstly, Brain Roche and Megan Murawski debuted the famous “Transformation Talk”. We normally give this presentation in preparation for an engagement with another team, but in this case, it was given to allow open criticism and circulation of our methodology to the rest of the company. We cover in this presentation: pairing, and why it’s important to our process, why we use TDD (Test Driven Development) (and why you should too!), and our weekly meetings including Retros, IPM, and Feedback to name a few. We had plenty of great ideas and questions, as usual, and we realized twenty minutes over time that we couldn’t get Brian off the stage.

Xuebin He eventually got Brian off-stage for a talk he conducted on CICD (Continuous Integration, and Continuous Deployment). Xuebin being one of the developers at the Dojo allowed him to be a bit more technical in his talk, and cover some of the programming practices and tools we use to achieve this at the Dojo. Concourse is our tool for running our beautifully constructed tests, along with standard mocking design patterns and the code quality produced with TDD.

We picked up again on Tuesday at 1145 to talk about why a PaaS exists, and why it’s important. That talk, given by yours truly, was focused on some of the common technical roadblocks that keep developers, customers, and managers from being able to work efficiently; as well as the ways using a PaaS can solve those problems to build a better business.

To containerize applications for a PaaS, we would need to learn basics like “What is a 12 factor application, and what’s a container?” Thinh Nguyen stepped in and gave a great description on how we use guiding principles while developing our application environment to be better for us and our customers.

Throughout all of our talks, we worked away on two pair stations very carefully brought from our lair in Cambridge. We gave away some free swag, some free candy, and raffled off some super giveaways. We thank everyone involved in preparing and executing these few days for their hard work. We also want to give a huge thanks to everyone who attended our talks (rambles) and participated in some mind-expanding conversations.

Finally, I want to close with a few notes. We always enjoy fresh perspective. If you had more to say, or you missed us during our time and you want to start a conversation, leave a comment in the comment section! If you don’t want to comment here, then drop us a line in my email. We’d love to hear from you.

Until next time, remember: Cloud Foundry, Open Source, The Way. #DellEMCDojo.

THE EVENT OF THE SEASON Coming to Hopkinton December 5th and 6th

Coming to Hopkinton December 5th and 6th

Before reading this blog post, I suggest that you and anyone that may be reading over your shoulder sit down. In your chairs? Great, because the excitement you are about to feel will surely leave you overwhelmed.

 

The event of the quarter is right around the corner! Please consider this your personal invitation to join us for DOJO DAYS next Monday and Tuesday, December 5th and 6th from 10 am to 4 pm in the 176 Café out at Dell EMC in Hopkinton.

official-dojo-days-logo

DevOps is a hot word in the world of technology. It represents a way of working and technique that aims at making the customer omnipresent in everything that is created and delivered. Companies today consider this way the future.

For this reason, Dell EMC and Pivotal paired to create the first ever Dell EMC – Pivotal Cloud Foundry Dojo. Our goals are centered around personal, team and company transformation. Through the practice of modern software development, we spend our days contributing to Cloud Foundry Foundation sanctioned Open Source projects through R&D modernization and methodology known as ‘the way’ (XP, Lean Startup).

Many know us as the team in Cambridge with great food and beverage (no really, it’s amazing- come visit us to see for yourself). We realize, though, that the commute isn’t ideal for most. So, we bring you Dojo Days to experience #adayinthelifeofthedojo, with a replication of our office environment and our team in action representing the steps we took to transform.

In addition to seeing #adayinthelifeofthedojo, you will have the chance to pair with us, join our team for lightning sessions that are driven by the audience’s goals (schedule below) and have the chance to win a Dell EMC Dojo branded Patagonia, S’well water bottles, t-shirts, and more!

 

The schedule of the lightning sessions are as follows. Please come by the Café day of to sign up and/or just drop in:

Monday, December 5th:

11:45 am to 12:45 pm: Steps to Transformation starring Brian Roche and Megan Murawski

2:00 pm to 2:30 pm: TDD and CI/CD starring Xuebin He

 

Tuesday, December 6th:

11:45 am to 12:45 pm: PaaS, and Why your Developers Care starring Gary White

1:30 pm to 2:00 pm: Factor, Cloud Native, and Containers (oh my!) starring Thinh Nguyen

 

If you have any questions, please contact Emily Kaiser at Emily.Kaiser@dell.com. Otherwise, we cannot wait to see you, your team, and all of your friends out in Hopkinton next week!

Bringing Cloud Foundry to You… Exciting Upcoming Events that the Cool Kids are Attending

Exciting Upcoming Events that the Cool Kids are Attending

For those of you who follow us on Twitter (@DellEMCDojo for those that don’t) or via this blog, I would guess it is pretty evident that we just love Cloud Foundry. We take pride in being a member of the foundation mostly because it is with this platform that we feel we are delivering and practicing what we preach; living out a true DevOps culture most conducive to productivity and quality product and delivery.

We are lucky enough to just be returning from Cloud Foundry Summit where upwards of 800 developers and other market adopters joined in Frankfurt, Germany to learn from other community members and to be a part of the PaaS’s business direction. With the Native Hybrid Cloud team, we at the Dojo spent our days representing DellEMC through presentations and booth shifts. We left feeling even more confident in our daily choice to use Cloud Foundry and to further evangelize the PaaS for the betterment of the larger technical OS community.

It is because of this that we are excited to announce that we will be hosting and supporting three Cloud Foundry Days here in the near future. Cloud Foundry Days are new, one-day educational events aimed at developers and operators who want to connect with businesses, learn about the platform, and share knowledge. The first that we will be hosting with the support of TIBCO, Pivotal, Telstra, Stark & Wayne, among others, is going to be taking place on October 18th in Sydney, Australia. If you have any interest in attending or know of others who may be, please find the registration link here: https://www.eventbrite.com.au/e/cloud-foundry-day-sydney-australia-tickets-27935602138. The second of these events will be taking place on October 20th in Melbourne, Australia and will also be supported by TIBCO, Pivotal, Telstra, Stark & Wayne, among others. The registration link for this event can be found here: https://www.eventbrite.com.au/e/cloud-foundry-day-melbourne-australia-tickets-27985249635. Last, but definitely not least, is the CF Day in Shanghai, China on October 25th where we will be supporting GE (Registration information to be available within the next day or two. Please contact us via twitter if you are interested).

We truly hope that these events will be fruitful in their reach and effectiveness, and help our technical community discern the best option for themselves and the businesses they affect. Teamwork makes the dream work!

A Fresh Developer’s take on Cloud Foundry Why the third platform is the new way to iterate

Why the third platform is the new way to iterate

Coming to the Dojo a little over two months ago for my first day of work at my first (out of college) job, I was mystified by the amount of understanding and knowledge I still had to gain by using the Cloud Platform as a development and deployment environment. After the first few weeks, we started developing a brand new application for internal use. There was no existing infrastructure, but a clear idea to use a SQL database, and a web portal for the UI. I was thrilled! I worked on my fair share of web applications, so this would be a cake walk.

Great! What were the IP’s? What was the endpoint? What was the downtime for our environment on updates? What was our server technology? They said it was up to me. I began thinking of asking IT for a VM spin up our database, scripts designed to back up the data with cron jobs, registering a DNS for our website, and for a potential duplicate set for our test environment; technical aches and pains that are first steps when building a web application. I then began asking what seemed the obvious question of who to go to for the resources, and I was told we would do it all ourselves. Wait, I thought, we were supposed to deploy and maintain the VM’s set up users for the database, download the applications, and backup technology? That was easily another two or three days short term, and days of complications long term. Or so I thought.

Except…I hadn’t known that we were using Cloud Foundry, and the benefits that came from this. All of the pain points I used to face in setting up a functioning web app were moot. Instead of spending time configuring and maintaining environments, the Dojo, as a team, has put together a full-functioning web application with production environment, architecture, an extensive automated testing harness, and automated deployment. All as painlessly as we might use Github.

Removing Development Roadblocks

When I thought of the Web application, a typical structure comes to mind of the architecture for the app.

Screen Shot 2016-08-31 at 12.20.49 PM

A typical developer headache for a web application

There’s plenty of steps for our team, as developers, to maintain and care about here. But with Cloud Foundry, we can remove many of these concerns.

Lets talk about Databases first. Using service brokers as provided through CF, we can simply bind a SQL service to our application. For extra sweetness, we can use a buildpack that supports that our server is connecting to a service-provided database. The buildpack will, at runtime, connect our application’s backend into a bound SQL database, no environment variables necessary.

Servers and UI? No problem. Pushing applications to Cloud Foundry takes as many commands as pushing to git. We can also update and configure the application directly through a UI included in our environment. This means changing something we forgot to put in our three-four deployment commands doesn’t warrant another deployment. As far as firewalls go, using the proper security groups to avoid exposing secretive endpoints is a few minutes behind the scenes of a UI, or a couple commands in a terminal.

Alright, so our development roadblocks are covered. What does all this mean for our Customers?

Rapid Integration and Feedback Loops

With our Test Driven Development and Continuous Integration mantras, we can rapidly iterate on our products. With Cloud Foundry, those rapid iterations allow us to take customer feedback. Using our real product on something as quick to set up and easily accessible as CF platform is, we can respond to our customer’s concerns much more efficiently.

Allowing our customers a way to directly interact with our product in this way is not only helpful for them, but for us, for a variety of reasons. Firstly, we’re able to get valuable feedback from them in a timely fashion, not when a feature has been done and untouched for two months (less old code touching, the better). Additionally, we can test what our real runtime environment will be like for our production level product, which means faster satisfaction for customers.

Screen Shot 2016-08-31 at 12.48.14 PM

Our development cycle. Made simple with less setup behind the scenes

Finally, we don’t have to worry about maintaining servers and VMS when they may go down. Cloud Foundry can sense when an app crashes, and restart it for us. Same database, same DNS, and limited downtime. Doesn’t get much easier than that.

Final thoughts

Using Cloud Foundry also means we can simplify our development process by having a consistent API and well-documented environment surrounding our application. When we rotate around our projects, people coming into our web application are using similar knowledge and practices they might use when deploying our Minecraft Docker Containers.

It’s for the reasons in this article, and I’m sure for many more to come, that the cloud platform and Cloud Foundry has made development easier for us. It allows us to create better products, faster. We can get immediate feedback from customers and get stories accepted faster. For most developers, that’s a no brainer.

Retrospectives Rock! Our way of ensuring continuous improvement: personally, as a team, and in the industry

Our way of ensuring continuous improvement: personally, as a team, and in the industry

There is great philosophical and factual validity behind the concept of empathetic reflection affecting positively people’s lives and interactions with others. Throughout history, people have focused their actions and reactions around this idea both subconsciously and consciously. A famous and often used example of this is the Examen as originally defined by St. Ignatius; the concept of through thoughts, words and deeds, reflecting on where you have been (further what brought you elation, sadness, stress, confusion, etc.), where you are, and aligning these things with where you want to go; continuous improvement of the self.

Here at the EMC Dojo, as our name literally implies, we practice “the way.” A large portion of this form of enlightenment is no doubt found in reflection as practiced through Retrospective, or an exercise our team knows as Retro. The exercise is practiced as explained in the aforementioned example as a form of continuous improvement of our methodology. We use the time to align everyone’s perspective and to ensure we are on the same page in terms of action items and overall goals.

Retro is done every Friday without failure. It is about an hour long and is attended by everyone who plays a role in the Dojo’s operations. Even when members of our Dojo family are working off-site, we ensure that a Google Hangout session is available so that they are virtually in attendance, as this is arguably the most important “meeting” all week. It is the time and space for every employee to speak his/her mind and do so with assumed positive intent, so that feedback can constructively be given and received.

The concept is simple: as a whole team, we are living out the mantra we preach. We are learning by doing; generating weekly action and reaction to our development process through empathetic honesty.    

The person running the exercise for the week (this is not assigned per week, but rather a spur of the moment volunteer) will draw on a white board three columns signified by a smiley face (things that went swimmingly), a neutral face (the so-so items), and a sad face (as your teacher used to proclaim “areas for improvement”). Then all members will add topics/items for discussion from the week to each of these columns as he/she sees fit. These items do not need to be evenly distributed by any stretch of the imagination. That is, no person or team collectively must add the same number of items to the smiley face column as they do to the neutral face column and/or the sad face column (this is part of the honesty piece).

The leader of the exercise will then address each topic/item on the board one item at a time from left to right or right to left (we do this to ensure that we are not making the retro top heavy in any one of the columns). By addressing the topic/item, we mean that the leader will ask the team who wrote the item on the board and why. This is where the importance of this exercise comes to play.

No matter the topic of discussion, in order for the exercise to work and for the team to reap all of its benefits, team members must be completely and empathetically honest about his/her contribution. By doing so, the team learns to navigate conflict by having uncomfortable, but necessary discussions. As with anything, with practice comes perfection. And by perfection, I mean the unattainable kind; something that we are still reaching for 🙂 All kidding aside, it’s true – with every week there are steps back that we learn from paired with giant steps toward our overall goals and methodology.

With the addressing of each topic, the team decides action items that are recorded on the spot. This allows us to ensure that we are offering more than an end of iteration wrap-up, and instead generating real actions and change to ourselves, our team and our organization. We are assessing our ability to break down and solve problems and make improvements –measuring, building and learning constantly in our development process (sound familiar?).

While the exercise was nearly impossible to complete during the birth of our DevOps culture, it is now something that we could not live without. Team issues are no doubt as challenging, if not more, than the technical issues we face. Luckily this exercise allows us to face both and do so with our core value of empathy at its center. We not only are then able to end the week (and iteration) on a high note, but also go into our weekend and following iteration rejuvenated. Retros Rock!

One Week at EMC Dojo

Latest posts by Brian Verkley (see all)

I write this while snacking on free banana chips I obtained from the lunchroom. A week in the Dojo is very different than a week programming at home or in a cube farm, and it has as much or more to do with culture than tools and process.

The EMC Dojo in Cambridge, MA (https://www.cloudfoundry.org/welcome-to-the-emc-dojo/) is a place that contributes code to the open source cloud foundry project using a specific development methodology built around pair programming, test driven development, and lean development, known as “the way”. They also teach the way to anyone interested in contributing to Cloud Foundry as well as other development teams within EMC. They earn the title of Dojo by literally being a “place of the way” .

From the moment I got there, I was a member of the team. I had planned to work in the same area, quietly observing the way while working on my own projects. That didn’t work out, and I’m so thankful it didn’t. On the first day, everyone in the Dojo had introduced themselves to me and were interested in what I was working on. They adopted my story into their backlog and encouraged me to attend their standup the next day and begin pair programming with them. I felt so valued before I had even added value. Before long I found myself pair programming on a PHP app (I have no experience in PHP) and doing anything I could to contribute.

They went to lunch together every day I was there, often participating in an office wide Yoga lunch or Go Programming Book Club. They cared about each other’s quality of life and personal hobbies. They struggled out loud with programming syntax and architectural design choices and often came together to discuss, solve, or vote. Every member of the team was heard and had the same weight in decision-making.

And it works. The speed and efficiency that they are able to take a story idea and turn it in to working code is amazing. And although they are all individually quite talented, there seems to be a “greater than the sum of their parts” thing happing with “the way”. They are completed unfazed by tackling something new largely because of their confidence that as a team they will be able to solve it.

What I witnessed, no, what I was a part of for my week, was a team of developers effectively coding for hours based on shared goals and methodology in an environment that made everyone happy. I’m so thankful to everyone who paired with me, shared with me, challenged debated and listened to me, welcomed me, and taught me.

What an outsider might notice first is the ping-pong table next to the cafeteria with available food and no checkout register, but that would be missing the point. The culture that they have built here and the benefits of developing in “the way” have left me with a lot more than this now empty bag of banana chips.

From Predicting Agile to Agile Predicting The need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

The need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

Luke Woydziak

Luke Woydziak

Director of Engineering at EMC
Luke Woydziak
Luke Woydziak

Often Agile teams shun the notion of predicting a date. After all, for teams to make a prediction seems anti-Agile. There is even a #NoEstimates movement afoot. However, in business and in my experience giving some ballpark idea of when something will finish is not only beneficial but also often required.

Estimating accurately is surprisingly difficult as items have varying levels of complexity, certainty, size and dependencies. At #EMCDojo, we believe in providing a realistic date for the various stakeholders of the project. I want to show you a couple of methods we use to do that.

Armed with these methods, I think you will find that the need for #NoEstimates fades when no estimate need be heavy-weight to be accurate.

Let’s get started. We practice the weekly XP practice of an Iteration Planning Meeting. This is where the journey begins. During this meeting, we look at items on the backlog do an engineering analysis to scope, add detail, validate assumptions and address open questions. After such analysis, we Roman Vote on the point value in less that 30-seconds per item.

A common scale of 3-points is often used to point the story (as a team we selected Fibonacci, but in my experience as long as this is held constant, the discrepancies are negligible). We enter these values into Pivotal Tracker as it is a great tool for Agile projects in that it automates the velocity calculation.

The week progresses with pairs of engineers pulling the top priority stories off of the backlog and working them to completion (with unit/integration and system automated tests). The Technical Product Owner for the team will accept or reject the story depending on the actual functionality matching the desired behavior. During this time, Pivotal Tracker will automatically track and calculate velocity and various other metrics.

Below is an analysis screenshot from a live project in progress with the CPT team. You can view the project at https://www.pivotaltracker.com/n/projects/1518687

Analytics

 

As you can see, the tracker reported velocity was 6 points during the month of March 2016.

Velocity

 

While the velocity is interesting, the real value comes when you observe it over time. Again Pivotal Tracker will help you with this. By clicking on the velocity report, you can view a more detailed analysis.

VelocityReport

 

The most interesting data point in this screen is the standard deviation (σ). We use this measurement to establish a high confidence interval (CI) and a reasonable CI for a given prediction (assuming a normal distribution, which is arguably a very big assumption). If you are performing sophisticated business modeling, these are the numbers you can plug-in to model confidently with.

StdDev

One word of caution:

Velocity is extremely susceptible to gaming. So I would strongly recommend against using it to compare across teams. It is far more useful as a predictive element as opposed to a diagnostic element.

 

In our case, we extensively use both epics and releases. You can view and export both as spreadsheets.

Releases:

Releases

Epics:

Epics

 

When you have exported the data, you will get a spreadsheet like ours of releases (if you use releases, however, you can apply the same analysis to epics):

Screen Shot 2016-03-10 at 3.39.07 PM

 

Zooming in on the projected column show us the projected completion date as calculated by Pivotal Tracker:

projected

 

This is a raw prediction; you’ll need to adjust it with the standard deviation (σ) and some calculations. First, let’s calculate the σ adjustment to get a reasonable CI:

  1. Find the velocity (6)
  2. Find σ (2.2)
  3. Calculate the multiplication factor:
    1. v / (v – σ) = adjustment
    2. 6 / (6-2.2) = 1.579

You can apply this adjustment to the time duration from now until the raw prediction in days to get a reasonable CI projected date. For example (the date that we took this measurement was on 3/10/16): The first release “V1 Volume Manager Complete” was projected to finish 18-days from then on 3/28/16. 18-days multiplied by the adjustment is ~28-days. Add 28-days to 3/10/16 and you get 4/7/16.

You can apply the same to get a high CI by using 2σ:

  1. Find the velocity (6)
  2. Find the 2σ (4.4)
  3. Calculate the multiplication factor:
    1. v / (v – 2σ) = adjustment
    2. 6 / (6-4.4) = 3.75

Now you can begin to see how certainty affects the calculation. The breakdown is as follows:

  • Projected: 3/28/2016
  • Reasonable: 4/7/2016
  • High: 5/16/2016

You can add the calculations to an Excel spreadsheet with the following formula: “=(((Projected-Now)*Adjustment)+Now)”

Screen Shot 2016-03-23 at 9.28.47 AM

 

Zooming in you can see the new columns:

adjustmens

 

Now you have some options when communicating predictions and planning non-development, but related activities. With the assumption that this is a normal distribution, the σ and 2σ adjustments represent 68% and 95% respectively. I deliberately used reasonable and high in place of those numbers as I think there is reasonable doubt about regarding the shape of the distribution. Of course, you could manually track those numbers and increase measurement quality. Also, note this is very project specific.

Let’s see how this all worked out. The first release “V1 Volume Manager Complete” was renamed to “CF Summit Demo Day” and completed on 5/26/2016 versus the high confidence date of 5/16/2016.

finalFinish

 

We were 10-days off of the high estimate. So what happened? Well as with all projects we discovered additional items/stories and most likely it’s not a normal distribution.

So we learn velocity alone will only get you so far and doesn’t account for the incoming rate, but for most projects two-weeks variances is within the ballpark. We used this method to plan for presenting a demonstration of Legacy Application support functionality at the Cloud Foundry Summit 2016.

Likewise, you can use this method to make lightweight and reasonably accurate estimates and go from worrying about predicting Agile to making Agile predictions.

Can we do better?

In my next post, I’ll discuss another method, that while it is a bit more complicated and labor intensive, it can decrease the variance and is flexible enough for you to apply across projects easily.

Steps to Devops. A Pragmatic Look at Lean EMC World 2016 Session Recording. Brian Roche Will Tell You How to Begin Your Transformation

EMC World 2016 Session Recording. Brian Roche Will Tell You How to Begin Your Transformation

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.

Steps To DevOps: A Pragmatic Look At Lean There is a secular shift at play within the IT industry. Traditional markets are eroding rapidly. As organizations seek to innovate using new digital business mediums, many are moving their infrastructures to the cloud. A major challenge they find is that building cloud apps not only means a whole new set of tools, but also a new mindset. In-house software capabilities are becoming a must to compete, but the transition to DevOps and the cloud is not an easy one.  At EMC World I described the steps we took to transform ourselves and adopt a DevOps culture.

 

Introducing Ginkgo4J Ginkgo for Java

Ginkgo for Java

Paul Warren

Paul Warren

Paul Warren

Latest posts by Paul Warren (see all)

Having been an engineer using Java since pretty much version 1, and having practiced TDD for the best part of 10 years one thing that always bothered me was the lack of structure and context that Java testing frameworks like JUnit provided.  On larger code bases, with many developers, this problem can become quite accute. When pair programming I have sometimes even had to say to my pair

“Give me 15 minutes to figure out what this test is actually doing!”

The fact of the matter is that the method name is simply not enough to convey the required given, when, then semantics present in all tests.

I recently made a switch in job roles. Whilst I stayed with EMC, I left the Documentum division (ECD) with whom I had been for 17 years and moved to the EMC Dojo & Cloud Platform Team, whose remit is to help EMC make a transition to the 3rd platform.  As a result I am now based in the Pivotal office in San Francisco, I pair program and I am now working in Golang.

Golang has a testing framework called Ginkgo that was actually created by one of Pivotal’s VPs Onsi Fakhouri.  It mirrors frameworks from other languages like RSpec in Ruby.  All of these framework provide a very simply DSL that the developer can use in his test to build up a described context with closures. Having practiced this for the last six months I personally find this way of writing tests very useful.  Perhaps the most useful when I pick up an existing test and try to modify it.

Java version 8 has included it’s version of closures, called Lambda’s.  Whilst there aren’t quite as flexible as some of their equivalents in other languages; all variable access must be to ‘finals’ for example, they are sufficient to build an equivalent testing DSL.  So that’s what I decided to do with Ginkgo4J, pronounced Ginkgo for Java.

So let’s take a quick look at how it works.

In your Java 8 project, add a new test class called BookTests.java as follows:


  package com.github.paulcwarren.ginkgo4j.examples;

  import static com.github.paulcwarren.ginkgo4j.Ginkgo4jDSL.*;
  import org.junit.runner.RunWith;
  import com.github.paulcwarren.ginkgo4j.Ginkgo4jRunner;

  @RunWith(Ginkgo4jRunner.class)
  public class BookTests {
  {
      Describe("A describe", () -> {
      });
  }
  }

Let’s break this down:

  • The imports Ginkgo4jDSL.* and Ginkgo4jRunner add Ginkgo4J’s DSL and JUnit runner. The Junit runner allows these style of tests to be run in all IDEs supporting Junit (basically all of them) and also in build tools such as Ant, Maven and Gradle.
  • We add a top-level Describe container using Ginkgo4J’s Describe(String title, ExecutableBlock block) method. The top-level braces {}trick allows us to evaluate the Describe at the top level without having to wrap it.
  • The 2nd argument to the Describe () -> {} is a lambda expression defining an anonymous class that implements the ExecutableBlock interface.  

The 2nd argument lamdba expression to the Describe will contain our specs.  So let’s add some now to test our Book class.


  private Book longBook;
  private Book shortBook;
  {
      Describe("Book", () -> {
        BeforeEach(() -> {
          longBook = new Book("Les Miserables", "Victor Hugo", 1488);
          shortBook = new Book("Fox In Socks", "Dr. Seuss", 24);
        });

      Context("Categorizing book length", () -> {
        Context("With more than 300 pages", () -> {
          It("should be a novel", () -> {
            assertThat(longBook.categoryByLength(), is("NOVEL"));
          });
        });

        Context("With fewer than 300 pages", () -> {
          It("should be a short story", () -> {
            assertThat(shortBook.categoryByLength(), is("NOVELLA"));
          });
        });
      });
    });
  }

Let’s break this down:

  • Ginkgo4J makes extensive use of lambdas to allow you to build descriptive test suites.
    You should make use of Describe and Context containers to expressively organize the behavior of your code.
  • You can use BeforeEach to set up state for your specs.  You use It to specify a single spec.
    In order to share state between a BeforeEach and an It you must use member variables.
  • In this case we use Hamcrest’s assertThat syntax to make expectations on the categoryByLength() method.

Assuming a Book model with this behavior, running this JUnit test in Eclipse (or Intellij) will yield:
Screen Shot 2016-06-02 at 8.31.35 AM

 

Success!

Focussed Specs

It is often convenient, when developing, to be able to run a subset of specs.  Ginkgo4J allows you to focus individual specs or whole containers of specs programmatically by adding an F in front of your Describe, Context, and It:


FDescribe("some behavior", () -> { ... })
FContext("some scenario", () -> { ... })
FIt("some assertion", () -> { ... })

doing so instructs Ginkgo4J to only run those specs.  To run all specs, you’ll need to go back and remove all the Fs.

Parallel Specs

Ginkgo4J has support for running specs in parallel. It does this by spawning separate threads and dividing the specs evenly among these threads. Parallelism is on by default and will use 4 threads. If you wish to modify this you can add the additional annotation to your test class:-

@Ginkgo4jConfiguration(threads=1)

which will instruct Ginkgo4J to run a single thread.

Spring Support

Ginkgo4J also offers native support for Spring. To test a Spring application context simply replace the @RunWith(Ginkgo4jRunner.class) with @RunWith(Ginkgo4jSpringRunner.class) and initialize you test class’ Spring application context in exactly the same way you normally would when using Spring’s SpringJUnit4ClassRunner.


  @RunWith(Ginkgo4jSpringRunner.class)
  @SpringApplicationConfiguration(classes = Ginkgo4jSpringApplication.class)
  public class Ginkgo4jSpringApplicationTests {

  @Autowired
  HelloService helloService;
  {
      Describe("Spring intergation", () -> {
        It("should be able to use spring beans", () -> {
          assertThat(helloService, is(not(nullValue())));
        });

        Context("hello service", () -> {
          It("should say hello", () -> {
            assertThat(helloService.sayHello("World"), is("Hello World!"));
          });
        });
     });
  }

  @Test
  public void noop() {
  }
  }

The nooptest @Test method is required as Spring’s JUnit runner requires at least one test class.

Trying it out for yourself

Please feel free to try it out on your Java projects. For a maven project add:

<dependency>
    <groupId>com.github.paulcwarren</groupId>
    <artifactId>ginkgo4j</artifactId>
    <version>1.0.0</version>
</dependency>

or for a Gradle project add:

compile ‘com.github.paulcwarren:ginkgo4j:1.0.0’

for others see here.

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.