The SitePoint PHP blog has posted a tutorial showing you how to use the Toggle library from Qandidate to handle the enabling and disabling of features in your application.

A frequently used development workflow in version control systems is feature branching. The idea is that we develop new features in branches other than the master one. After a feature is tested and ready to be released, it is merged back into the master branch or a release branch for deployment. This approach helps us develop new features without disturbing the main code base.

However, developing a feature branch might take much longer than a normal release cycle. [...] One of the techniques widely used as an alternative to feature branching is feature toggling. Feature toggles (or feature flippers) act like on/off switches. [...] We can temporarily hide a partially built or risky feature (release toggles) or limit finished stable features to a certain group of users (business toggles).

They introduce the basics of the Toggle library and it's main components: the Manager, Toggles, Operators, Conditions and Context. These are all combined together to help determine if a feature should be enabled or hidden. Examples of each are included along the way as well as one showing a toggle in action. They also show how to integrate it with a framework, in this case a Laravel project as middleware. The post ends with a look at strategies, giving you even more customization around the conditions of the toggle (example: Affirmative, Majority and Unanimous), statues and creating the conditions from either YAML or array configurations.

The Qandidate blog has a new post today that "pulls back the curtain" as to how they manage their development process and get their work done.

At Qandidate.com we tried a lot of different project management tools and techniques. After two years of experimenting I want to share our current process, seen from my role as product owner (PO). One reason for sharing this, is to help you improve your process, but the most important reason is to start a discussion with you based on your experience, to improve our process even more. Our main rule at Qandidate.com is to embrace change. Always be open for changes that may or may not improve your process. If a change improves the process it’s a win. If you didn’t try it you will never know!

They walk through the three main points over the overall flow of work there:

• The process itself including two week sprints containing (unestimated) stories
• A demo and stakeholders meeting showing the work they've done during the sprint and get feedback from the stakeholders
• The stories and how they're created and when/how new ones are added (their "piano meetings").

They also include testing, both frontend and backend, and focus on small chunks of functionality instead of quick and dirty hacks. While their process won't work for every group (and is more of a "scrum-but..." setup) it is interesting to see how another group does their work.