What Are the Workflows of Prominent PHP Community Members?

Workflow refers to both the process and the tools that are used in this process. Almost every developer comes up with a process of creating and finalizing the project deliverables. This process is implemented through a set of tools that the developer comes up with through trial and error. Once a workflow has been perfected, developers follow the process almost religiously because of a simple reason: following workflows reduces most of the management problems that developers have to face during a project.

Since developing workflows is a matter of experience and trial and error (a very distressing process), many experts recommend that budding developers should try and study the workflows of other known developers. Over time, these new developers would come up with their own toolkit for project development, as they adopt what works for them and discard what doesn’t.

Here are some of the PHP ecosystem’s most popular developers and designers, and their tools and/or workflows. Note that these workflows will by no means be comprehensive, but even mentions of tools used by some of the more prominent members of our community should be enough to warrant checking them out.

Twitter | Linkedin | GitHub

Taylor Otwell, Creator of Laravel

• Currently, Blackfire.io is my favorite tool for profiling PHP applications. It provides an easy-to-use interface and quick approach to identifying troublesome parts of the application.

• For continuous deployment, I typically rely on Forge and Envoyer, two services I created myself.

Taylor also discussed his workflow in depth in this Hashnode AMA – check it out to find out specifics.

Twitter | Linkedin | GitHub

Phil Sturgeon, Software Engineer at WeWork

• Vagrant and Docker help keep projects wrapped up and isolated, so most of the time I use those if the dependencies are complex enough to warrant it.

• These days, I’m working mostly on APIs, so a lot of the time, I just pull down the Git repo, composer install, php -S or run the test suite.

Twitter | Linkedin | GitHub

Stefan Priebsch, IT Consultant at thePHP.cc

• I usually work with PHPStorm, PHPUnit, phpab, PHP_Depend, and PHP CodeSniffer.

• I recently started to use an interesting new tool called dephpend, a very promising dependency analysis tool that can detect architecture violations.

• Of course, I use Git as version control and Jenkins for continous integration, though I do not usually set up a CI server for my private projects.

Twitter | Linkedin | GitHub

Nicolas Grekas, CTO Blackfire.io

• On the hardware side, I use a nice Fujitsu laptop, with two additional screens (that’s three screens with my laptop’s, but I mostly use two of them.)

• On the software side, I use Ubuntu, Git, vim, a terminal, and a browser.

• I also sometimes use qgit, write in Sublime Text, and have a Windows VM to debug issues there (yes, Blackfire works also on Windows!) or to use PowerPoint on.

• I may be wrong, but I tend to think that the slowest part of my development experience is my brain, so I don’t feel the need for a fancy IDE.

• Docker Compose for booting the Blackfire stack locally, and more recently the soon to be publicly released SensioCloud, to reduce infra setup to a simple port tunneling.

• On the project/quality management side, we use Github, Splitsh, Jenkins, Appveyor, Zendesk, Jira, Slack, and a few others.

Twitter | Linkedin | GitHub

Adam Wathan, Software Entrepreneur and Author

Here’s some of my favorites:

• 27″ 5K iMacfor 99% of my work

• 13″ Retina MacBookPro, for when I need to work on the go

• Sublime Text 3 for all development work

• Sequel Pro for working with MySQL databases

• Airmail 3 for email

• Todoist to keep track of what I need to get done

• iTerm 3 with ZSH as my terminal

• Github for all my repository hosting

• Laravel Forge for provisioning servers

• Envoyer for zero downtime deployments

Twitter | Linkedin | GitHub

Manuel Lemos, Founder of Icontem and phpclasses.org

Since 2006 I standardized my PHP project development using Use Case Mapping:

• My each project is divided into Sub-systems like: blog system, forum system, mass mailing system, social networking system, gamification system, etc..

• Each subsystem is composed of Use Case (User Story) classes that act like controllers. They handle HTTP requests or some other kind of input, call Service classes to perform actions like accessing a database or a remote system.

• For database access I use an ORM code generation tool called Metastorage that I have been developing since 2002. It takes a object relationship definition from a XML file and generates code for PHP classes for accessing data of each class objects.

• The tool generates final code, i.e. code that does not need to be edited after being generated. It also generates database schema definition files that allow installing and upgrading the database schema without further concern on the exact SQL statements that are needed to update a schema.

Nowadays it is normal for 50% of my PHP projects code to be generated by Metastorage. This means it made me much more productive, working less to achieve more, and use more reliable code, as Metastorage generates type checked code.

Twitter | GitHub

Josh Lockhart, Founder of Slim Framework and PHP The Right Way

• I use Vagrant to manage a unique Ubuntu virtual machine for each project.

• I provision each virtual machine and my production servers with the same Ansible roles to ensure both environments are exactly the same.

• I prefer PHPStorm for writing code.

• I use Composer on 99.999% of my projects.

• I write and run tests with PHPUnit.

• Version controlling is done through GitLab, which in turn triggers continuous tests on either CodeShip or Travis CI.

• I manage deployments with Capistrano. It’s a solid workflow that has taken several years to discover and refine. But I’m super happy with where I’m at.

• Docker is tempting, but I don’t believe it has matured enough for me to easily use and manage it in production.

Twitter | Linkedin | GitHub

Eryn O’Neil, Speaker and Consultant

I work on lots of different projects, most of which were started by someone other than me. So many things in my development workflow change from project to project. However, the following things are always (or mostly) consistent:

• I use a Dell Developer Edition 13″ XPS with Ubuntu. (The Developer Editions ship with Ubuntu installed and Dell guarantees driver support. I also rely on my portable Roost stand and external keyboards & mice.

• On the software side, I develop on Ubuntu in vim. I’ve got a .vimrc and some plugins that make life easier.

• I use Vagrant to separate my local development environments. Scotch Box is an amazing out-of-the-box Vagrant experience, which helps me get started quickly on new projects where I don’t have access to a development environment or existing VM.

• I manage projects with Github Issues and their newish Projects feature (basically Trello-style boards integrated with your GitHub repository). For higher level project management, I use Insightly to keep everything straight.

Twitter | Linkedin | GitHub

Cal Evans, Runs Nomad PHP, elePHPant

My workflow for new projects usually follows this pattern.

• Open Sublime Text and write 20-40 lines of procedural PHP to see if the idea works.

• I design the database if a database is needed. Not all projects need a database. Even if info like config options need to persist, a lot of times a simple config file will suffice. For the database design, I stick with MySQL Workbench. It’s been my tool of choice for many years now.

• Walk through the workflow: If I designed a DB for the project, then this step is mostly done already. If not, I walk through the workflow. Sometimes I diagram it out, other times, I just start making a list of the objects I think I will need. I usually WAY over-design and only use about 1/2 of the objects I list. If this is an API, I list out all the Endpoints I think I will need. If it is a website, I list the pages. Most of the time, it is a CLIproject and I start with the commands I will need. Since I use symfony/command for everything, it makes it a good starting point.

• Build one Command

  • Build the command and make it work.

  • Break out any new objects discovered in the process into discrete objects

  • Write unit tests for the command

  • Commit to the repo

• A word on Unit Tests. If this is a project that only I will ever use, no I don’t usually write Unit tests. If ANYONE else will be involved, yes, I write them. I usually shoot for about 70%-80% code coverage.

• Regarding repositories, yes, almost EVERY project I build these days is under source code control. Again, my workflow differs if it’s just me vs. working with others. If it’s just me, I will usually work in the master branch if this is a new project and a new branch if it is an iteration on an existing project. If others are working with me, I usually adopt feature branches.

• Iterate until it works: Note I didn’t say “until it’s done”. Every project I’ve ever built is incomplete. There are always things I can add, new features, new options, refactoring, I asked an artist friend of mine “When do you know it’s done?” He replied that art is never done. My code doesn’t rise to the level of art, but I agree with the sentiment.

  So that’s how I work. My indispensable tools are:

• Composer

• PHPUnit

• Git

• Sublime Text 3

• MySQL Workbench

• Docker

• Slim framework for APIs

• WordPress for websites

• Symfony/console for everything else

Twitter | Linkedin | GitHub

Kat Zien, Senior Software Developer at Brightpearl

My development workflow is pretty standard.

• I use Trello or github/gitlab issues for planning. I use a bunch of editors depending on what I’m working on. Vim if it’s bash or just quickly editing something.

• PHPStorm for PHP, Gogland for Go – been happily using the JetBrains family for years now.

• I recently started using VSCode from Microsoft for Go or bash scripts as well, and so far I really like it.

• As for techniques, I try to do TDD but I would be lying if I said I always do that. Sometimes if I’m doing something exploratory I’ll skip the tests and just dive in, and worry about refactoring and testing later.

• I do love my code tested though, so for longer projects I’ll set up Jenkins or Travis CI to run the tests and code coverage for me.

• If I’m writing Go, I’ll write some benchmarks as well to make sure my code is performing well. Go has a lot of great tools built in, such as race detectors or runtime profilers, so I’ll usually use those when working on a project.

I like contributing my code via pull requests, whether it’s personal projects or at work, so my workflow is pretty much based off that. Create a request, get it code reviewed, merge, then the tests run and off it goes to our continuous delivery pipeline. Unless it’s a one-off simple project, automating as much as I can is key! :)

Twitter | Linkedin

Laura Elizabeth, Creator of Client Portal and Design Academy

I’m a designer and my partner is a developer (we’re both business owners) so our workflows are very collaborative.

• We do our planning on paper and use clubhouse to organise our to-do’s.

• My partner will start coding the basic structure, including filling in the content while I jump into Photoshop and start mocking up some visuals.

• We use Fractal to define components and we start styling up some core components like buttons or particular modules that will be reused.

• We use Atom for editing and BitBucket for development.

• For one of our apps (http://rightmessage.io) we’re using Laravel :-) others are simple WordPress websites or plugins.

Conclusion

From the above lists, some workflow ideas are very clear:

• Linux is the preferred development environment. Developers do use Windows or other OS, but only for testing and application compatibility verification.

• Developers love Docker and Vagrant to manage their projects.

• Jenkins and Travis CI are the suggested tools to manage continuous deployment with GitHub and GitLab

• Git wins unanimously for version control, and most people like to have tests but don’t write them for personal projects.

• The choice of IDEs and code editors is very personal and varies from simple text editors, to modern text editors, to full IDEs. When it’s an IDE, however, the paid PHPstorm seems to be preferred over free alternatives like Netbeans.

What are some of your workflow specifics? Did you find common workflow ground with any of these developers? Let us know what approach your development process takes, and maybe we’ll come away with the ultimate list of tools no one’s heard of but should have!