Postman Team Sync

Postman Sync is here and is a pretty powerful tool to use with a distributed team and even more recently announced was the public offering of this branded Postman Cloud Basic. All your collections are synced to the Postman cloud (just as they were with sync enabled on a single account). This provides so much more seamless testing than you can imagine. Once your team is setup and individuals are linked, have the new beta application and are up to speed on Postman collections and how you want to organize and write them they all have read/write access to the shared collections that you setup. When anyone edits (and saves) a single test or collection it is automatically synced up to the cloud and back down to the other team members. Before team sync my solution for this was to use a single Github repository to store and update all the Postman tests used by the team. This as you can imagine isn't an optimal way to synchronize files between distributed members (we could have used other file/collaboration sync tools like Dropbox, Box, or Google Drive but opted to use Github Enterprise instead).

Postman Environments

Having multiple environments that we wanted to test and validate the API in (UAT, Staging, and Production) we started using Postman Environments and heavily making use of environmental variables which are powerful tools within Postman to accomplish this. However this required each member of the team to know when a new variable was added and manually go and re-import these settings into their Postman installation (very cumbersome). Beyond just having people manually go and "re-sync" these variables I started to notice everyone on the team didn't know why tests would start to fail due to having {{resource_id}} as the id used in the RESTful path to a resource instead of the replacement value. This caused a bunch of people to just start to claim that these Postman tests were "brittle" and "un-manageable". Knowing this wasn't the case I started to look into alternatives that would solve this problem in the wider sense.

The Team Sync Beta was also missing a feature to sync Environment Variables (and Global Variables) across our distributed team. There could be a number of reasons for this: to have local non synced variables, no expose user information, etc. Whatever the reason was for this not to be part of Team Sync I found "a solution" to our problems. I say "a solution" because I know full and well that this isn't the "only solution", just one that I feel is the easiest to customize and build upon.

Before we get to that I want to give a shout out to the Postman team for also building a behavior testing framework that you can use in your Postman Collections too. I have found this to be much easier than using the native setup for testing, and beyond that encouraged me in the solution that I have gone with for syncing environment variables across distributed teams.

Behavior Testing Framework

I would encourage anyone and everyone to take a look at the blog post made by "shamasis" from the Postman Team. This blog post outlines how to get a behavioral test environment setup for use in Postman. Have been using this since this post was published and have loved this so much that I have encouraged my team and other API engineers I know to do a similar thing. It would be awesome if this was just part of Postman, but I also understand keeping things as light as possible to allow teams to take things in their own directions, but this is a welcomed addition to my Postman Collections any day (I was previously using a self created script that has similar, but not all functionality as this).

Postman Sync Boilerplate

I have gotten into a habit of always including a default setup for any collection that I use. The following is the barebones of that collection containing a single folder called /_setup which is purposed to run before any other folder or test to make sure the environment is "setup" before running tests.

Each one of these "tests" are pretty self explanatory. however the third test requires a small amount of setup before they will function as desired. Since we are attempting to load a specific environment you will need to create a local environment and the only requirement is that the environment contains a single variable in the following format (postman:environment=environmentName where environmentName matches exactly to the environment file within the github project you are attempting to sync with). The boilerplate github repository I have created as an example just has 2 environments localhost and production. obviously for a real solution you will probably need to modify this to have more than just those two, but for an example structure this is a great starting location.

Now after running the /_setup collection you will have a fully up to date environment within your local Postman installation for whatever environment you have selected (ie. localhost or production) as seen below.

Now your distributed team can manage the environment variables used by their shared Postman Collections via Pull Requests to Github. While having an easier way to have those variables synced into their local Postman environment by simply running the /_setup collection when there are changes to these variables.