CakeDC Blog

TIPS, INSIGHTS AND THE LATEST FROM THE EXPERTS BEHIND CAKEPHP

CakeDC Git Workflow - Tips and Tricks

Over the past months we've had many people ask us about how to integrate and work with the CakeDC Git Workflow as we do. So, here are few tips and tricks on how to use our workflow for the git version control system, to help you keep a clean commit history on every CakePHP project.

Using ticket numbers in commit messages

One thing which becomes pretty obvious early on is how handy it can be to have commits tied to your issue tracker. The easiest way to do this is to use the issue or ticket ID in your commit messages. $ git commit -m "#1234 changed this and that" Following this pattern (starting the commit message with #ID), with a bit of git rebase sauce, makes the lines of your updates read like a story of your code.

Automation with use of commit-msg hook

It's possible that you may not using a git bash prompt, so you don't see the name of the current branch in console all the time. Alternatively, the dialog window of your preferred UI for git may not clearly disclose the name of the branch you're working on. Or, maybe you're just too lazy to write ticket number every time you commit something to the repository. Using our workflow, where non-permanent branches are named after the related ticket number, you can create an executable file .git/hooks/commit-msg in the project's root directory with following content: #!/bin/sh TICKET=$(git rev-parse --abbrev-ref HEAD | awk -F '/' '{print $2}') if [ -n "$TICKET" ]; then echo "#$TICKET `cat $1`" > $1 fi From now on, the message of every commit to any branch with a forward slash in the name (in our case, its always the ID of the related feature/issue/hot-fix ticket), will start with a hash and the ticket number. Also, lets assume that you're using our workflow for all of your projects. In that case, it could be better to install the git hook globally: $ mkdir -p ~/.git_template/hooks ... add global hook(s) to this directory ... $ git config --global init.templatedir '~/.git_template' After setting this up, every created or cloned repository will use this template directory (will make copy of its content). Existing repositories could be reinitialized with the new template by running git init in their root folders.

Temporary local branches

With the previous commit-msg hook in place, we can now go crazy with temporary local branches, while still maintaining a readable project timeline with references to tickets. Changes don't have to be committed directly to published branches, and here are some examples how to do that.

Local branch for debugging

Debugging sometimes takes a lot of code to be written, and sometimes a few of the changes made during debugging need to be merged and propagated. $ git checkout -t origin/feature/1234 $ git checkout -b debug/1234 Now we have local branch debug/1234 based on feature/1234. Lets do some work in loop, like adding tests, debugging code, applying fixes... everything in commits as small as possible, with meaningful commit messages: $ git commit -m "Added debug code for debugging this and that" $ git commit -m "Added test case proving this and that" $ git commit -m "Tried to fix this and that" The history of the debug/1234 branch will look like the following: #1234 Added debug code for debugging this and that #1234 Added test case proving this and that #1234 Tried to fix this and that We'll still have the feature branch free of debugging related code. You can then merge to this branch to keep it updated with progress from feature branch, but you can also commit fixes to it that you'll want to publish, and then use cherry-pick for including them elsewhere. And if you changed something in your debug/1234 branch, that you'll want to still see in the feature/1234 branch, then simply perform the following: $ git checkout feature/1234 ... merge, cherry-pick, rebase ... $ git push Then, finally some clean up, like so: $ git branch -D debug/1234 We hope you found something useful here, to make working with the workflow more engaging, and help you keep building awesome applications with CakePHP.

Comments plugin 1.3.0 released

We've just released version 1.3.0 of the CakeDC Comments plugin for CakePHP, with a collection of revisions and fixes, as well as an update of the code for 2.5, and a reformat of the documentation inline with the CakeDC Plugin Standard. The Comments plugin lets you easily add comments to any model in your application. The comments structure can also be defined as "flat", "threaded", or as a "tree". To use the plugin simply include it in your application, run the schema or migration to add the comments table, then add the following to your controller: public $components = array('Comments.Comments'); Then, all that's needed is to include the comments in your view, using the following: echo $this->CommentWidget->display(); You'll probably notice that we did nothing with the model. This is handled internally by the plugin, although you can customize the behavior, or use the callbacks provided. The component also boasts a selection of configuration options, to help customize the integration. The plugin also includes an admin interface, for managing your comments, and you can also use the widget helper to define the output or customize via templates. This plugin as well as many others are released as Open Source, free of charge, and maintained by contributions from the CakePHP community. We thank all of our contributors to the Comments plugin, and hope the continued involvement helps keep your favorite framework ecosystem healthy and strong, with a wide range of great plugins to help build your applications.

The annual CakePHP conference

As most of those in the community know, CakeFest is our annual conference, dedicated to everything CakePHP. It's an impressive event, where developers from all over the world come together, share their secret recipes, and talk about baking awesome apps. It's an invaluable opportunity to mix with other talented developers, learn new approaches and techniques, and network with the community at large. With the third major version of CakePHP on the horizon, and a celebration of the project's nearly 10 years of Open Source goodness, this really is an event you don't want to miss. The event itself lasts 4 days, and is broken into two areas. The first area, covering the first 2 days, are the developer workshops. These are hands on sessions with the core developers of the framework, where we show you the best practices and methods to getting the most out of CakePHP. They really are an awesome introduction to the framework, and a headfirst dive into the internals of the project. These are also divided into both beginner and advanced sessions, so everyone attending can get as much out of the workshops as possible. We're also really friendly and involved in the process, to you can reach out to any of us for hands on tips and tricks, or just to get an opinion on your own approaches. The second 2 days are dedicated to the conference part of the event, where a wide array of international speakers will be giving over 20 talks and presentations on CakePHP and related technologies. It's also where we have some of our conference activities, such as the core team Q&A session, where you can pitch your questions directly to the core developers of the framework; an hour of lightning talks, for both newcomers and those with little experience at speaking to give it a shot; the Hour of Contribution, where we introduce you to the Open Source process and open collaboration; as well as our raffle and prize giveaways. And, of course, what would an event like this be without some real cake? At CakeDC we've always been actively involved in organizing, sponsoring and running the conference over the years. For those who don't know, Larry Masters, founder of CakePHP, is also the president of the commercial entity behind the framework. Over the past 8 years we've held the event around the world. From Buenos Aires, Argentina and Berlin, Germany, to Manchester, England and San Francisco in the United States, we've gone all around to make sure we can reach out to as much of the community as possible, and give everyone a chance to get their piece of the cake. This year's event will be hosted in the beautiful city of Madrid, Spain, from the 21st until the 24th of August. So be sure to grab your ticket now, and join us for a jam packed event. You or your company may even be interested in sponsoring this year. Either way, don't miss out on the landing of the big three point oh! See you there.

Tags plugin 1.6.0 released

Version 1.6.0 of the CakeDC Tags plugin for CakePHP has just been released, with an array of fixes and improvements, updated the code for 2.5, and also reformatted the documentation inline with the CakeDC Plugin Standard. The Tags plugin allows you to tag anything in your application, including an additional semantic layer to your models. Getting started with the plugin is easy. Just include the plugin, run the schema or migration to add the tags table, then add the following to your model: public $actsAs = array('Tags.Taggable'); That's it. Then, finding tagged records is just as simple, by using the "tagged" find type, for example: $this->Tagged->find('tagged', array('model' => 'Post')); Alternatively, you could find all records by a specific tag: $this->Tagged->find('tagged', array( 'by' => 'awesome', 'model' => 'Post' )); As you can see, using the plugin is a breeze. Adding tags to form takes no extra effort either, simply add the input to your form, and the behavior takes care of the rest. $this->Form->input('tags'); The plugin also comes packed with an admin interface, for managing tags, as well as a tag cloud helper, as a great addition to your applications. Check it out here, and give it a try. All of our plugins are released as Open Source, free of charge, and maintained by the many contributions from the CakePHP community. We thank all of the contributors to the Tags plugin, and hope that the continued involvement helps keep the framework ecosystem healthy and strong, with many great plugins that help you build awesome applications.

CakeDC Git Workflow - An Introduction

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
So, we set out to define a process which would allow us to meet these goals, and help us deliver projects, without the pain of the managing that process itself.

Organize and coordinate

When 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.

Iterating through milestones

At the core of the workflow is the concept of milestone development. A milestone represents a deliverable, and is broken down into 3 phases: development, qa and staging. Each of these has a dedicated branch in the repository, which holds the work completed at each step of the process, and ensures that all work done on the project follows through these phases. The milestone also helps organize the development team as well as the client (product owner), as the workflow keeps everyone in a cycle, which helps avoid feature creep and sets clear and coherent objectives and responsibilities at each point in the process.

Quality as the driving factor

At CakeDC our ultimate objective is to deliver the highest quality possible. This means that all members involved with a project need to provide the best possible to meet that common goal. We do it because we care about what we're building, and want the result to match our expectations as to what the "best" means in each case. Our workflow keeps that philosophy in high regard, as its designed to protect the code base at all times from anything which doesn't meet the grade. Each phase acts as a barrier to avoid the master branch from being compromised.

We Bake with CakePHP