Over a million developers have joined DZone.

The Codeship Workflow: Developing a New Feature

· DevOps Zone

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

With this blog post we start a new series about how we work on the Codeship. Many people asked us how we develop features, about our workflow and which apps we use every day.

This blog post focuses on the workflow we use to implement a new feature: from branching away from master until it is ready for the pull request. The following blog posts will talk about our internal communication, how we do pull requests and code reviews, and an in-depth look at our deployment strategy.

Git Branching Model

We follow the GitHub-flow model of development (check out Scott Chacon’s article, so whenever we start a feature we create a feature or bug branch. Most of our team uses git-extras by visionmedia for this.

The Codeship Workflow – Branches

Typically only one person works on one branch. If we need more people to work on a feature, we break it down to the smallest possible chunk that one person can ship.

For example, consider one of our latest improvements: Ben, who joined us in July, implemented a first basic version that allowed us to invite collaborators from GitHub. He worked on his own feature branch and had a simple UI that was ready to be shipped. After the feature passed the pull request and code review, his changes were shipped.

Then Alex created another feature branch from master and implemented the final user interface, which makes it super easy to invite anyone to the Codeship who committed to the GitHub repository.

The Codeship Workflow – Teammate Invitations

Both committed and pushed regularly while still working on the feature. When a small piece is done, we typically push it to GitHub to run our complete test suite. While Codeship runs all of the integration tests we keep working on the feature.

This way we very quickly see if our changes broke any part of the application without running the full test suite locally. Breaking a feature branch is absolutely OK. We want our developers to push early and often and let Codeship take care of the tests so they do not waste time.

The Codeship Workflow – Steps of your builds

There are numerous advantages in shipping a minimum viable feature first. We keep waiting times between the developers to a minimum while still shipping improvements very quickly. Thereby we remove a lot of unnecessary communication. And we never run into any kind of merge problems when two developers work on the same feature.

Of course, there are challenges with this workflow. Sometimes features are shipped with the expectation that they are improved right afterward, but something else needs immediate attention. This way the improvement can take a bit until it is shipped. Therefore, getting that minimum viable feature right is very important -- big enough to be valuable, but small enough to be shipped fast and by a single person.

We are very interested in your workflows, so please leave a comment about how you are working on new features. If you have any questions leave a comment, send us an in-app message or a tweet to @Codeship.

Next time, we will show you how we go from code to pull request, code review and then merge into master. Stay tuned.

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.


Published at DZone with permission of Florian Motlik, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}