Our GRID product receives updates continuously. Perhaps you may receive an email letting you know about the new features or perhaps you suddenly discover that there is a new link or button that makes the GRID experience more enjoyable. No matter how you discover the new feature, our goal is that by the time you see the new feature it is polished and working at making your life easier. So lets take a look behind the scenes of how a new GRID feature makes it way from my desk as an engineer working on GRID to you, a user of GRID.

First, let me start by introducing the GRID cast of characters,

GRID Leads:

• Ben – That’s me. I write the code that makes GRID work, so I am the Product Lead for GRID.
• James – Most of you will know James. James does the GRID training and is the person who answers many of the GRID queries that come to us. James spends the most amount of time with clients and knows what features will make GRID most useful, so James is our Support Lead.

GRID Team Members:

• Tracey – Tracey is the latest addition to the GRID team and has been taking on more of the GRID testing to let James spend more time on things like training. Tracey will be picking up more of the level 1 support for GRID so next time you give us a call about a GRID issue and Tracey picks up the phone she will probably be able to answer your question (and wait until you see what she’s done with the GRID Help manual in the near future, too).
• Serge – Serge is one of our software engineers and will be picking up more of GRID tasks into the future.
• Piers – Like James, most of you will know Piers. His day job is to be the Director of Gaia Resources but every so often he gets pulled into the GRID team as a subject matter expert (or he jumps in unannounced to keep us on our toes).

Now, onto the tale of a new GRID feature…

Our story begins when I type the final keystroke and declare the new feature perfect! Bah typical engineer hubris. That is why the first step^* after finishing a feature is to write automated tests. Automated tests are small code snippets that can be run independently to tests parts of GRID. The great thing about automated tests is that you write them once, but you run them often – and since it is the computer running them, it never gets tired, it never complains and it never makes a mistake. They are great at picking up problems where I add a feature or fix a bug but introduce a new problem somewhere else in GRID. So I write the tests for the new feature and then run all the automated tests to make sure no new bugs have been introduced. Now it is time for a code review.

The idea behind a code review is that two pairs of eyes looking over a piece of code are better than one. Serge and I are now working on the GRID code reviews together, and his job is to go over my code meticulously to try and find any problems that I have overlooked. He is going to try things like type in nonsense input or upload corrupt files – essentially anything he can think of to make my code break. It is a bit of a game that we play. I try to make my code as robust as possible, and he will try his best to break it. It keeps life interesting and it helps to make GRID a more stable product for you. If he is happy that the code is stable, he will pass the review and the code is merged into the main GRID source repository.

When the code is merged into the GRID source repository, our continuous integration server detects the change and runs the automated test suite. This happens automatically every time. If a problem is discovered the system sends out an email and it becomes the offenders responsibility (usually myself) to fix the issue. This should never happen of course, so it is a bit of a humbling/shameful experience to break the build – what was I saying about engineer hubris? Still its better to break the build than to deliver poor quality software. When the build passes it is time to update the staging server.

Each GRID instance has two servers – a staging server and a production server. The staging server is where GRID gets tested aggressively. This is usually done by the support team, James and Tracey. They know how GRID gets used in the real world. They know the mistakes that users tend to make and how users expect the system to behave. They are the main point of contact when it comes to GRID support so this is their chance to test the system and make sure that they are happy with the quality of the latest version because when it goes out to you the client, they will be the ones on the receiving end of your phone calls. Often they will also involve the client point of contact to test the latest version of GRID to make sure that the new feature is working as expected.

The ground rules when it comes to the staging server are,

• Do not put any valuable data on the staging server. Testing happens here and as such, you may lose your data since it does not get backed up.
• We will internally update the staging server as new work is completed. This means that the server may go ‘down’ from time to time without any notification.

If the support team and the client are both satisfied, the support team lead James will organise with the client for a time when the production server can be updated. When that happens the new feature becomes available to you.

The whole thing is outlined in the diagram below…

So, what’s new in GRID?

The following is a list of new features in the June GRID update, which we rolled out a month or so ago and has bedded down really well.  We’re about to release another update thanks to some additional work commissioned by the South West Catchment Council (SWCC) across all of the GRID instances in the near future.

Baselayer

• When you search for Baselayers/User Layers or Activity Layers the list of results will show a legend icon. Clicking on this icon will navigate directly to the symbology screen.

Miscellaneous

• The “Data” menu has been renamed to “Baselayer” (Administrators Only)
• “Managed My Layers” has been renamed to “Manage User Layers”.

Bugfixes

This update of GRID includes fixes for several bugs.

Baselayer

• Upload of non GeoTIFF files will be rejected with a message.
• Upload of shapefiles with a space will be rejected with a message.
• Label symbology can now have a halo of zero.

Baselayer

• Non-required image fields can now be cleared successfully.

Bulkdata

• Shapefiles that are not point, line or polygon geometries will be rejected with a message.

Backward Incompatible Changes

Bulkdata

• Shapefile templates will no longer contain spaces. Spaces have been replaced with underscores.

We’ll have some more to include in another GRID release in the near future, as we’ve been working on additional enhancements to GRID over the past month, thanks to the additional funding from SWCC!

If you have any questions about our GRID release procedures please get in touch with us directly, via our Twitter, Facebook or Linkedin pages, or leave us a comment below.

Ben

* Some people like to write tests first and then the feature second – its mostly a personal choice.