How It's Made: Unity API Edition

[Timothy_Cosgrif]

The Unity API is nearing its 10^th version of being in our software, released in OnBase 8; it has had many features added to it from that initial version way back when. However, just how does a Unity API Feature become a thing? The simple answer is that a Hyland developer creates it, but there is a lot more to it.

Documentation

To begin, the most important part of this process is the way it is tracked. That is with the “Software Change Request” or SCR as it’s known here. These SCRs can come from various sources such as discovered defects, internal requirements, support requests, and even these forums. No matter where they come from, they will all eventually make it to the first step of the process: Product Lead Review. In this step, the Unity API Product Lead will look at all of the information on the SCR to help make some decisions. Specifically, should this SCR be completed during this release cycle? The Product Lead considers many things while making decisions. This includes the amount of work already slotted for the current release, the business problem this SCR is trying to solve, the number of customers associated with the request, or the amount of pain the SCR might be causing for the end-user.

Design

Once we have decided to complete an SCR for the release, the next step of the process begins the design. Over the years of developing the API, we have created a set of design standards to keep the public interface consistent because of our promise of backwards compatibility between releases. We also have a set of standards for the internal structure of the code but I will not go into that today. The design typically goes through a series of reviews to get as many eyes on it as possible. In many cases, with large public changes, we consult the Custom Solutions Group to review our designs and give feedback, as they are a large user of the API.

Development

After the design is finished and approved, it is time to finally do the development of the feature. The SCR assigned to a developer and placed in an upcoming sprint. The developer is responsible for developing the functionality to the design and writing unit tests to ensure each segment is functionally correct. The developer submits a code review to others on the team. Once the code review comes back without any glaring defects, the developer can then check the code in. This check-in triggers a CI process to begin. It will build the code, run all of the unit tests, run some code analyzers, and output the built assets.

Testing!

Once developed and through CI, it is time to test. Testers of the API need to be developers, so they have access to the source code. They typically work with a local build with the changes to write their tests. They will write tests to ensure the functionality will work as a whole. Typically, these will be automated tests. We strive to automate as much testing as possible since it just makes sense for an API. The tester is also responsible for ensuring the Documentation is correct, writing release notes, and determining if there is any further Documentation needed in the SDK. If there are UI changes that contain any text that can be translated, the International QA team will ensure these translations show up correctly in different locales.

Conclusion

Once all of the above steps are completed, the SCR is complete. The feature is ready to be used by all of our end-users.

And, from beginning to realization, that's how an API enhancement gets made! We hope that sheds a little bit of light on how we do things around here and what kind of work goes into each new Unity API feature. As always feel free to ask any additional questions you have about the SCR process in the comments!