General Slicejack’s Development Workflow
As a developer you’ve probably got a certain workplace workflow that you’re used to. You use it to get stuff done as efficiently as possible. That workflow is called a (software) development workflow. In this post I’ll introduce you to the specific development workflow that we use here at Slicejack.
Every development workflow has a set of tools that go with it. Naturally, so does ours. So, before I start talking about how we develop stuff here’s a list of tools we use daily as a part of the whole development workflow:
- Git (as a version control system)
- SourceTree (as a Git client)
- BitBucket (for remote git repository hosting)
- Vagrant (development environment virtualization – click here to learn more)
- JIRA, Basecamp (issue and development tracking)
- Slack (internal communication)
Now you know what we use let’s see how we use them. Let’s go through a typical project development workflow.
1. Planning
Let’s say we’ve just got a new project. A project we need to build along with information/specs that show us how the site or application should appear and act. The first thing we need to do is create the project analysis and planning. In this step we look into the received specs and look for potential issues and missing pieces of information.
The next stage is to break the whole project into the smallest possible pieces which we call features. Having a feature list is great because it’s much easier for us to estimate how much time it’ll take us to develop individual features. Equally, we can understand which features might cause issues in the development process. Also, by knowing how much time the feature development will take we also know how much time it’ll take to develop, test and fully deploy.
Finally we get back in contact with the potential issue, missing pieces and estimate how much it’ll take us to put the brand new site or application online. We also assign features to the developers who work on the project. Assignments are sometimes written into the JIRA project but sometimes we like to do it the old school way. Yes, that’s right. Good old-fashioned post-it notes and our trusty office wall.
2. Environment setup
Each project type requires a specific environment. Since we mostly build customized WordPress solutions we have our own virtual development environment (see Vagrant) optimized for WordPress development. This is something we like to use for local development. Next we create a git repository on the BitBucket and set it up for development. Each team member clones it to his own PC. Now we’re ready to rock n’ roll.
3. Development, branching and versioning
With Git, team members can easily work together. We do the frontend and backend development in the same repository. We mainly do it at the same time since we’ve already defined which features must be implemented along with how they’ll perform. As the Git repository is also used for deployment purposes we needed to implement some form of Git branching workflow. Why? Because our master branch always needs to be deployable.
One solution was to create a “development” branch in which we’d just push individual commits (large or small). Once we have them tested, merge the development branch into the master and deploy. That solution might work just fine when you have a very small team but as the team grows you’ll run into merging and rolling back issues. In order to make things work in a larger team we decided to implement a feature branching where each individual feature would have its own branch with all associated commits.
Those branches would be branched out from the master branch and then merged back to master by using pull requests. We also sometimes branch out the “development” branch which we then use to merge all features together. We test them before merging them to the master just to ensure we won’t create problems with the master branch in the merging process. This workflow enables us to:
- Do a rollback with ease
- Merge code much faster and easier
- Have a tested and deployable master
- Assign code reviewer(s) to each individual feature merge request (pull request) if necessary
Now that we have a development workflow we can talk about projects that are supposed to be versioned. A versioned project is a project that will have a certain set of features associated with a certain release (version). This means that you should already know the following:
- Release date for a certain version (deadline) or time that will take you to develop
- List of features associated with a certain version
Now you can use the “git tag” command to tag a certain version of the site. Having the code tagged you can deploy a certain version of the site or rollback to a certain version on production as well.
4. Tracking
Development tracking is important as we need to know if everything is moving as planned. Project tracking can be done in many ways. One of the ways that we use is to use the “resolved over total” graph in which we can see how close we are to completion. If you have a bigger project it would be a smart move to set up a few extra milestones (for example weekly or monthly). This is done just to see if we’re on track with the deadline and to act accordingly. Tracking can be done manually or automatically by using JIRA.
Along with the issue tracking we have short meetings every Monday morning and at the end of every Friday. Here it gives us a chance to talk about active projects and issues that we’ve encountered and resolved. We also do a little thing called daily scrum where we notify other team members about what we did the day before and what we’ll do today. Daily scrum can also be used as a development tracking source.
5. Internal communication
Internal communication is an important part of any company. It’s vital since team members must be able to communicate with other colleagues about work and non-work related stuff. At Slicejack we use Slack for internal communication purposes where we have separate channels for each project that we are working on.
We also have a channel for development and also a general channel for random issues. It’s a wise idea to have those channels separated because we don’t want to mix work related with non-work related messages. We want to be able to mute out channels that can potentially distract us.
6. Deployment
The last and final step in the initial development process is the deployment. Deployment can also be done in many ways, right from the old school FTP down to the git deployment. We use various types of deployment depending on the platform we deploy to. For example deployment to our own server is done by using one type of deployment. The WPengine using git deployment way documented by the WPengine itself and so on. No matter which way we deploy it, it always comes up to deploying code from the master. This has all the features needed to be implemented for that specific release (version).
7. Extend and adapt
This development workflow is easily extendable and adaptable. This means any person or any team can adapt it to their own needs. You may have already seen it but we’ve mostly implemented the Atlassian Software Development Workflow. This is because we use most of their tools during the development process.
There we go. The Slicejack development workflow in a nutshell.
