One of the major features listed in our roadmap for 2017, with the usual safe harbor statements firmly in place, is adding data support to Gearset. We thought now would be a good opportunity to give you an update as to where we are, and the decisions that we’ve made.
What have we been up to recently regarding adding data support?
Over the last number of weeks we’ve split our efforts into two main streams of work:
- Performing technical spikes into how best to implement data support with the most powerful functionality possible. Just as migrating your metadata in Gearset is a simple process, we also want an equivalent experience when it comes to migrating your data. By taking a little more time to work on such a significant feature, we believe the end result will more than justify our approach.
- Talking to users to better understand what people need and the problems they’re looking to solve.
Both of these stages have been hugely beneficial and helped us come to a decision regarding the direction we’re going to take with adding data support.
What do we mean by data support?
Unsurprisingly, ‘data support’ means different things to different people. We defined three categories or descriptions of what we mean by data support to help us decide:
- Migrating configuration data: Including custom settings data, and custom objects data (e.g. reference tables for ZIP code lookup or records controlling application behaviour)
- Data sampling for debugging and testing: Choosing specific records from standard and custom objects for debugging and testing (e.g. three account records and related records)
- Migrating data for environment creation: Replicating data wholesale from one org to another (e.g. for creating a new developer environment or refreshing a sandbox from production)
What we’ve decided to implement
After reviewing our survey results and re-listening to many hours of research calls (thanks again to our wonderful volunteers who took part!), we’ve decided to start with data sampling.
One of the things that became clear during our research was that starting with sampling - picking a set of objects, identifying relationships, filtering for specific records, and then recreating those records and relationships in the target org - is a great first step towards solving the other problems described above too. In a good number of cases, environment creation doesn’t mean taking all of the data from the source and replicating it in the target - just a selective subset. Similarly, a good chunk of configuration data can be handled in the same way.
Of course, we’re already aware of additional requirements and layers of complexity that we’ll need to consider going forwards. However, we think that taking this approach will allow us to deliver a solution to a real problem that our users are facing in a relatively short period of time, which we can then iterate on in the presence of feedback and extend to support more complicated use cases.
When will data support be available in Gearset?
We’re now ready to move from our technical spike to start building the feature, and are aiming to release a first (very) basic slice in the latter part of June. It won’t be the finished article by any means, but it will provide a first step towards providing great data support in Gearset.
If you’ve any questions about data support, want to provide feedback on any of the above, or simply get in touch to say hello, just email us at [email protected] and we’ll be happy to help.