How to implement a comprehensive API-first framework that meets the needs of agile development and DevOps
By Steve Davis, CTO of Four51
An API-first framework, or product, allows customers and developers to innovate rapidly. The API product must be capable of reacting to bug fixes and feature requests quickly. It’s an expectation of the developer who has most likely been involved in internal only software development environments. Your API is now a part of their overall development plan and you cannot be a bottleneck to their progress. Traditionally, even within SaaS software platforms, release cycle times were measured in months, not days. With the proliferation of Open APIs and microservice architecture, your API must be capable of the expected release capability or it will be rejected. The right way to enable this is through quality DevOps.
One of the pillars of a continuous integration strategy is to always be deployable. Simply put this means you should always have a repository of code that can be deployed to your production environment on a moment’s notice. Enabling this while also allowing for multi-faceted feature development can be managed in various ways. The two major distributed version control systems (DVCS), git and mercurial, support the requirements for continuous integration.
One of the more popular and effective workflows is the “Git-flow” method and a variation promoted by GitHub’s engineering team called “Git-hub flow”. If you are inclined to use mercurial, there is a similar method named “Hg-flow” that was inspired by “Git-flow”. The concepts are simple and they work for small and large teams.
With the “Git-hub flow,” the only required rule is that the master branch should always be deployable to production. Any new features should be branched and named descriptively. Once that branch is ready for deployment, you can create a pull request and merge it into master. Merging code can present conflicts at times, though, so choosing a good merge conflict tool is important. You should also strive to release the master branch as quickly as possible once the merge has occurred. The benefits are clear –– you are pushing new functionality rapidly.
Believable progress is very difficult to demonstrate with an API-first platform. Frequent production releases provide this insight. Your marketing team has something to promote and your executive team sees tangible progress.
As with any new process or methodology, there are legitimate concerns that will be brought forward. One of the primary considerations is stability of the deployment and quality assurance. The continuous integration strategy addresses these two explicitly.
First, the methodology itself offers greater stability by design. Because the feature branches deployed should be isolated and consist of less code changes, the impact of the deployment is minimized. Monitoring the activity immediately after deployment will shed light on any unintended side effects and, if a problem is discovered, your team can address the problem, create a fix and deploy rapidly. Because the release doesn’t contain a vast amount of changes, any disruption is generally minimal and the recognition of the right fix is usually obvious.
Secondly, the quality must be covered by a comprehensive unit test routine. There are a number of good unit test frameworks, but the key for your team is to implement rigid controls around how they are managed. Unit tests should all pass before any pull requests are created. Your build system should also run all unit tests during its automated build, stop the build process on any failure and notify all developers of such issues. If there are failures, the entire team should focus on creating a solution to bring the build back to a stable status. Integration testing is also extremely important. It is different from unit testing in that it’s generally more focused on testing the system as a whole rather than testing individual methods in isolation. Your team should strive to perform these tests in a clone of your production environment. You’re hitting a homerun if your integration test routine is capable of creating and tearing down environments during the build process.
An API-first framework presents challenges that are not present in application development. Applications are used by humans, and humans are generally good at adapting to small changes without much fuss. APIs are used by code, which is generally not as good at this. When an API changes, all code that uses it must also be changed, tested, and re-deployed. Applications have control over actions of users, through a UI, that shape the intended usage. APIs offer developers opportunities to stretch the intended usage and potentially to go far outside the bounds of intention. Unit tests are crucial to ensuring the integrity of the API base so developers can feel confident that major changes are less likely to disrupt users. Having quality unit and integration tests is essential to ensuring your development process is stable, reliable and capable for rapid development and deployment.
Today, the expectations for a rapid delivery of software is normal. A sound DevOps strategy is critical to support an Agile development workflow. Getting your operations right allows your development team to focus on delivering, which benefits your customers and your organization.
About the author:
Steve Davis is CTO of B2B eCommerce solutions provider Four51, 
and has held the role for nearly a decade. Steve has been working in technology for about 20 years, starting in his Navy days, which helped him develop a strong but motivating leadership style. Visit www.four51.com for more information.