Its been almost a year now since we released, and then later open sourced, the CakeDC Git Workflow at CakeFest 2013 in San Francisco. Since then, we've had loads of feedback, and have also experienced ourselves how it's revolutionized the way we work on projects. When we first set out to define the workflow we had some issues which we wanted to resolve. The main ones being broken staging servers due to unstable branches, an unorganized planning of QA on a build, repeated efforts when testing code which is constantly changing, and messy repositories with no clear organization. Having these problems at hand, we wanted to accomplish a couple of goals:
- Maintain a master branch which is reliable as a stable and versioned code base
- Provide a staged code base that's stable and best represents the upcoming version
- Allow new releases to be comprised of multiple milestones (or sprints)
- Allow developers to create features from the code developed by others
- Allow the next milestone to start while the QA process is still active on the previous
- Allow QA to review code on an isolated branch without affecting the stage server
- Isolate bug fixing on separate branches to avoid active development during QA
- Provide a process which can be planned around and scheduled for QA and releases
Organize and coordinateWhen working with a team of managers, developers and testers, it becomes very important to keep your sanity by organizing and coordinating efforts on projects. When these projects are large in size and scope, that can become a difficult task, especially if you don't have a clearly defined process at hand. And that doesn't just mean defining a series of steps to follow, but a process which sets the team's direction, and facilitates the desired results. The CakeDC Git Workflow does just that, by setting out a clear path to follow, and key points in which members of the team are involved, from managers and developers, through to QA testers and client review. These break down as the following:
- Development: After gathering requirements and planning out a milestone this is the first phase. During this time the code base is actively worked on, and can be considered unstable, in a bleeding edge state. Each ticket is developed on a feature branched from the develop branch. Peer review would take place on each feature branch before it reaches develop.
- QA: Once the first phase of development is complete the QA process begins. This is performed on an isolated branch, so the next milestone could commence. The acceptance criteria defined from the requirements would be applied here. Any bugs found by the testers are fixed on an issue branched from the qa branch.
- Review: Once testing has concluded and the code base is considered stable it's merged to the stage branch, and a milestone is tagged. The client or product manager would now review the results and provide feedback.
- Release: Once the work completed in milestones constitutes a new version of the application the code from stage is merged to master, and a release is tagged.