With the release of ReadyAPI v3.3.0, the team here at SmartBear has completed the first round of work on a rethought Git workflow – all available directly within the tool. We recognized early when talking about improvements to Git support in ReadyAPI, that it was imperative we take a step back and reframe the existing integration around overcoming obstacles. Especially the challenges users faced when building projects as part of a small or large group.
This month’s release culminates the release of both v3.2.5 and v3.2.7 over the last two months. This method of delivery represents a shift in the way ReadyAPI has traditionally been deployed – moving from larger, quarterly releases to more focused monthly releases. We’re excited to share this update with you and look forward to feedback and continued improvements as we move into the second half of 2020.
Teams & Testing
At SmartBear, we’re fortunate to work closely with users who fill many different roles, have different responsibilities, and in turn have many different expectations about the application. We’re also fortunate that our tooling is used in a wide array of industries – from highly regulated sectors like Finance and Healthcare to more flexible technology organizations. It’s always illuminating to see exactly how common the challenges teams face are. When striving to build and deliver high-quality applications and services at an increasing rate, it doesn’t matter what project they’re working on, the team they’re part of, or the industry their organization operates in.
Across organizations around the world, large currents move us together towards new technologies and delivery strategies. Many organizations are in the midst of what’s coined a digital transformation: the effort to shift legacy applications towards a leaner, more flexible network of smaller services. We’re seeing teams form around these smaller services, giving them more flexibility to change and progress their applications with the technology that works for them. It enables them to release and update at their own pace, and in turn, take on feedback and refocus based on their application partners and consumers needs. This adjustment, along with the evolving way they work, reflect a common goal in the technology space – to react more quickly to shifting consumer needs and meet the deployment challenges the future will demand.
Teamwork and collaboration are essential parts of enabling this transformation. There are countless services whose purpose is to enable closer communication and help manage a process around how teams work together. While ReadyAPI strives to be the industry’s most powerful API testing platform, we recognize we need to be part of a stack, and enable collaboration in a way that lets our platform improve quality and process. We can’t be a bottleneck.
There’s no cookie-cutter way a team looks or works. For our application to serve the widest array of needs, we focused on the broader challenges teams face, and not be as prescriptive with pairing our test building tool with where tests are being stored and managed. We think improving the full workflow within the tool can help teams not only overcome current challenges, but also enable them to discover new ways of working together and with our application.
The first opportunity in improving Git support for ReadyAPI was in our connectivity to the platforms and services that provide repository management services. These shared platforms are critical to the team process, and in many cases, are the places an automated process will look for the most recent project updates of a CI/CD task.
With the release of ReadyAPI v3.2.5 in April, the team built a new authentication process called “Account Management,” that lets users input credentials and have them stored at the application level. This way they’re easily reused across interactions with remote providers. This could come in the form of retrieving a list of repositories, or simply pushing changes or opening a pull request without having to re-enter authentication values each time. The ability to reuse and maintain a connection to a remote provider would lay the foundation for the rest of the features that would come in the subsequent updates, as well as define an application level space for us to work with shared credentials.
User experience is a critical aspect of any application, but it’s especially important for ReadyAPI since it provides an incredibly wide array of functionality, extensibility, and flexibility.
In ReadyAPI v3.2.7, the user experience of working with a repository was our main focus, and saw the release of an updated Git dialog to house all of the repository interactions in a single place. By bringing these actions together in a central place, updating the dialog with information on changes as they happen in a project, as well as exposing new functionality to enable more complete Git workflows – such as the ability to create new branches, or open a pull request from with ReadyAPI – we believe our users will more easily make Git interactions a part of their everyday workflow. And more clearly understand the relationship between changes in a project they’re working on and its impact on the rest of their team.
When working as a team, large or small, one of the most common challenges in using Git workflows is cleanly resolving change conflicts. In previous iterations of ReadyAPI, this would mean parsing through layers of XML and Git merge errors to understand exactly what was in conflict, then trying to resolve them directly in the project files without breaking the project itself. This made it easy for projects to be corrupted, work to be lost, or for changes to be moved forward without a clear agreement on their implementation to avoid creating more issues.
With ReadyAPI v3.3.0, we introduced a brand new Merge Conflict dialog. At a high level it shows three projects – a local version currently being worked, the remote version with changes coming in, and the resulting project that will be used when conflicts are resolved.
By separating these views, we’re now able to show exactly where in a project conflicts exist. Only now it’s in a visual style that matches our navigator’s project tree and allows users to make more informed conflict decisions. After going through and choosing resolutions, these can be applied as a batch action and the project is updated to meet the decisions of the user.
There was a concentrated effort to make our Git interactions and workflows as flexible as possible. We believe the following best practices will help teams create the best workflow when using version control and ReadyAPI:
Separating tests & code
- Some teams that integrate development and testing more closely will look to bring code and tests together into a single repository, which may help simplify the ‘movement’ of these assets together and keep application changes in line with testing changes. But it does limit the ability for test assets to follow a lifecycle of their own and be broken away from code repositories down the line. We believe that by storing projects in their repository, we can not only enable workflows through the integration in ReadyAPI, but we can also start a standalone process around test creation, reuse, and versioning.
Making use of branches
- Branching strategies are commonplace when working with application code, but in many cases overlooked when talking about test assets. As the number of team members working on a project grows, defining a strategy for how they make and bring changes together is key. If users are working together on a single branch, each small change will have an immediate impact on other's work. This can create unnecessary noise and undue conflicts that, in many cases, would be resolved through the ‘finalization’ of changes. By working across separate branches, and making use of push/pull workflows, and merging capabilities, teams can more seamlessly work together on separate but related tasks.
Defining a pull request strategy
- Many requirements for test changes are part of the definition of done for implementation tasks. In a branching workflow, the ability to merge my changes into a larger main branch is the penultimate step to sharing work. Pull requests are a chance for changes to be validated and tweaks to be shared before updates move forward. Pull requests are a step that is still served well as a manual step – having that chance to collaborate on decisions without being a part of the actual test creation process – while in smaller projects automating this stage of the workflow can help expedite the larger delivery process. It’s important to understand the benefits and trade-offs of using a manual or automated pull request workflow, as well as explore the benefits of a combined strategy.
The team at SmartBear hopes that you enjoy the updates found in the new ReadyAPI v3.3.0. It’s our goal to help teams build the highest quality software possible and push forward on test creation efficiency.
We’re open to feedback and suggestions, as well as input on how we could help improve your team process. We look forward to delivering exciting new functionality throughout the rest of the year, and working closely with our users to deliver the most powerful API testing platform the market has to offer.