Software development teams like to move fast and stay on the cutting edge of innovation. And in order to produce great software, they have to use the latest and greatest tools. But changing or upgrading tools can bring unwanted security concerns that many companies can’t afford to risk. So, how can a software development team stay current without risking their intellectual property?
That was what the development team at Global Healthcare Exchange (GHX), a healthcare technology company, was thinking about when they picked Bitbucket Server for their Git solution.
GHX connects hospitals and suppliers through a cloud-based trading exchange. Their software lowers costs and helps increase operational efficiency: hospitals can care for patients, and suppliers can focus on developing new products instead of worrying about healthcare supply chain headaches.
GHX makes software for a heavily-regulated industry and their software development products needs to meet certain security standards. So when it came time to choose a Git tool, Michael Johnson, head of GHX’s Change and Release Management Groups, said that they didn’t feel comfortable forklifting “our intellectual property onto someone else’s server.” And as a result, they went with Bitbucket Server.
The decision to move from ClearCase and SVN to Git
GHX’s Git journey began in 2012, when the popularity of Git in the greater developer community got the attention of Michael and teams at GHX. The appeal of Git when compared to ClearCase, SVN, or Perforce was obvious when researching the branching capabilities that Git provides – it seemed like a robust and powerful way to develop software.
Likewise, GHX knew that if they wanted to be at the forefront of software development trends, they needed to adopt Git to keep up. As a result, GHX moved from IBM’s Base ClearCase to Git with the goal of adopting an agile practice across their 70+ developers in 2012. They soon realized Git on its own wasn’t well protected due to user management. So in 2013 they brought in Bitbucket Server – formerly known as Stash – to protect and manage their source code.
GHX decided to use Bitbucket Server for various security reasons. The gut reaction of the release management team when they were switching to Git was to keep intellectual property where the company resided. Tools like GitHub made them nervous because their code wouldn’t be behind the firewall and they would have to punch a hole through it to let users login. With Bitbucket Server, the level of permissions that an administrator has at his or her disposal to put security measures around how people login made it easy to meet certain criteria for accessing code just by having user authentication.
But admins were not the only team members that benefited from having granular permissions. When a team sets up a pull request workflow, permissions in Bitbucket Server manifest themselves in features like branch permissions and merge checks. Branch permissions, for example, allow teams to control the actions users can perform on a single branch, branch type, or branch pattern within a repository.
Merge checks bring control to a custom workflow by setting checks as to when a pull request can be merged. Pull requests can’t be merged if the required checks have not been met.
Merge strategies is another feature that functions similarly to merge checks where you can choose a merge strategy to squash or fast-forward changes when merging. These are the kinds of features that bring control to the development process and give teams the freedom to focus on the task at hand: coding.
Bitbucket Server and software development best practices
The reasons to go with Bitbucket Server were rooted in security concerns, but what Michael and his team found after using Bitbucket Server is that proper levels of security bring about best practices and can push how teams manage code towards continuous integration.
Developers can constantly integrate code and focus on green builds by using Bitbucket with other Atlassian tools. The development process at GHX starts with Product Management entering each new project as a Jira Software story. Engineers pull these from the queue and begin developing, using Bitbucket to check in and manage their source code, and Bamboo to run automated builds and tests to capture bugs and issues before deploying. They create a Jira Software ticket representing the release activity, and manage this ticket to facilitate their release cycle until it goes out to production and becomes available to customers.
Or, as Michael says, “the integrity of the tools and process can bring more meaningful authenticity to why and how developers develop products.”
Already have Bitbucket Server? Upgrade to the latest version.