Software Development Workflow: New Features

Codeship NewsDevOps

Reading Time: 3 minutes

Update: We have released a free ebook about our workflow: Efficiency in Development Workflows.

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 blogpost focuses on the software development workflow 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 into our deployment strategy.

Our software development workflow:

The 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 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. And breaking a feature branch is absolutely ok. We want our developers to push early and often and let the 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 afterwards, 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 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.

Sign up for a free Codeship Account

Next time we will show you how we go from code to pull request, code review and then merge into master. You can read part 2 here.

Further information

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • We are working only on the master branch in combination with feature-flags which allows us to toggle features on and off per environment.

    • Do you run into frequent merge problems?

      • Nope, not really!
        I think the reason for this is that basicly everything is separated/isolated (ocp).

    • Kris Leech

      How? Do you merge the feature only in to staging branch (which is deployed to staging server), it is tested and then is merged in to master if approved?

      • There is no merging, we flag the features. You can imagine that as a
        if (enabled) do_this else do_that end
        everything is in the master branch

  • Adam Thody

    Hey guys, great share.

    I love the workflow benefits of feature branching (pull requests, code reviews, etc.), but in my experience, those branches tend to live too long, which effectively means the team is no longer continuously integrating. The tests may be run against their branch, but not against their changes in combination with other current feature branches.

    Do you have any thoughts/comments/advice on this issue? How have you addressed this in your workflow?


    • Hey Adam,

      it definitely becomes a problem when feature branches live too long. Our approach is to break down features into very small parts that can be done in 1-3 days. There are of course exceptions where it takes longer, but this is rarely the case and we can manage it as it happens so rarely.

      But generally when branches or pull request are lying around for a few days it starts to feel very unpleasant because we get the feeling of loosing control over that branch or feature, so we really make sure that it doesn’t happen.

      Longer term when our team grows as well we will separate out our current app into several smaller ones to keep the overlap as small as possible.

      One of the features we are looking into and want to eventually implement in Codeship is pull request testing. Github allows to pull the merge for a pull request and run tests on it. This will be very helpful to at least make sure the tests run before you merge. Currently we are testing every branch by itself, but not the potential merge.

  • Anthony Cintron

    Hey Florian,

    Thanks for sharing your Git-flow process. We too have a similar process to Scott Chacon’s Git-flow.

    I believe our process is a bit elaborate. We integrated our custom Kanban process into our Git-flow process. We consider each touch point during the development cycle to be a way to vet/test ones feature. We have an upstream with specific touching points: Red environment is for developers to vet/test their own work and is categorized as Development In Progress (forked repo); Green environment is for System Testing (company repo); Staging environment is for User Acceptance Testing; Lastly, Master is our production state.

    Our process really puts the responsibility of code quality on the developer very early on in the process. Red is not integrated with Codeship. It is our cowboy environment and allows engineers to remote test their work. Our engineers have to run tests locally. However, this may change at some point and we may include Codeship into the Development In Progress stage.

    When an engineer has a completed a Marketable Feature, the associated code is sent as a Pull Request. There after I begin my code review. Once code passes code review, I then deploy to Green. Once Codeship passes, I begin System Testing (Pre-UAT).

    Our process is a little more elaborate than what has been explained above. I believe in a nutshell, we love the idea of a continuous quality check and making all stakeholders responsible for their work. This includes the engineer, tech lead, product owner, and UAT coordinator.

    Ideally, we should be bringing Codeship earlier on into the process. We haven’t quite figured out how to do this gracefully, but it’s a work in progress :-)

    Either way, Codeship is the Bomb-diggity! I especially love the Coveralls integration as it has automated our coverage evaluation process (Which is another conversation).

    • For us this workflow would simply be a little too much overhead, but it seems to be working great for you guys.

      Regarding running the tests on your local system, we really believe that should not be necessary any more. Running only the tests necessary for the feature locally and the whole integration suite on a CI server (or Codeship) gives the developers a lot more time.

  • Great post! I’ve been using git-flow since some months ago, but I don’t really like having to create a release every time I deploy changes to my production server. I’m definitely going to give your workflow a try.
    Thanks for sharing!

    • Git-flow works really well for software that has longer release and support times. But if you want to push a couple of times a day it’s just a lot of overhead

  • nXqd

    I find that the git fow is not suitable for the current fast pace environment. We focus only on master branch then each member can create the our branch to work on, then rebase if needed and create pull request. If that PR is accepted, we push to live.

    • We’ve experienced exactly the same. Creating special release branches every day or even a couple of times a day is just too much overhead

  • Pingback: real #productmanagement: workflows from real teams (in refinement!) | wasabigeek()