Whenever I’m in the process of working on something for a client, my usual setup is something like this:
- Work on the code on my local machine’s development environment
- Keep the code in source control using GitHub
- Use Dploy.io to deploy the latest commit to a staging server
- Repeat until ready to launch
Straightforward enough, right?
But there have been a couple of times when I’m working with designers or front-end developers who need to work on, say, CSS files while I continue to do some of the backend work.
If they’re comfortable working with source control, then granting them access to the repository of the project and having them commit their changes to be part of the deployment process works fine.
But what about the case where the frontend developer is going to be working on various styles that you won’t personally be touching, and they aren’t using source control during the development phase of the project?
Small Team Source Control
To be clear, I’m not advocating having only part of a team use source control, and part of the team ignore it. Generally speaking, if you’re using source control, then you should be all in.
But there are times where this isn’t going to happen.
Case in point: Say you’re working on a very small team where you’re working primarily on backend code and you’re not concerned with what the styles look like for whatever it is you’re building.
In that case, it is possible for you two to work asynchronously while still maintaining your deployment process an without overwriting any of the files that your teammate is working on.
For the purposes of this example, assume the following:
- You’re working on on functionality in the WordPress dashboard
- Your teammate is working on styling whatever elements you introduce
- You keep all of your dashboard-specific assets in an `admin` directory
So with that said, here’s a way to go about setting up a process.
1. Create an Empty CSS File
First, create an empty CSS file in your
admin/css directory. Ultimately, this is the file that your partner will be working on and that you will not be touching.
From there, go ahead and setup a hook to register the file so that it’s loaded with the rest of the dashboard stylesheets:
From this point forward, you shouldn’t touch this file. The only action that should ever happen is that you retrieve this file from the staging server (but I’ll cover that more momentarily).
2. Deploy Your Changes
Continue to work on the features, issues, and whatever else you’re responsible for building specifically for the dashboard.
Obviously, if you’re doing any markup, you’ll want to make sure that you’re giving proper
class attributes so that your frontend developer can access them using the file created in the first step.
Regardless, as long as the elements work and respond in the way they are supposed to, then the way they look doesn’t matter – that’s not your responsibility.
3. Download The CSS File
As your frontend developer works, feel free to pull down the file at anytime. Permitting you’re communicating well, the changes should “just work” and you should be able to commit the file to source control.
The process remains the same:
- Don’t touch the file or files that are outside of your area of responsibility,
- Periodically pull them down from the staging environment,
- Check them into source control
At the very least, do a final pull of the file from the staging environment into your working directory so that you can commit and tag a final version.
Developer Legalism and Caveats
Again, I’m not advocating that only part of a team use source control, but the reality is that there are instances in which you may be working with a designer or a frontend developer who is primarily concerned with writing CSS, pushing it up to staging, and repeating the process.
And that’s fine. Sometimes it’s worth finding a streamlined process that works well for small teams rather than getting caught up in the legalism of practices that developers are known for pushing.
If you happen to be working with a team with someone else like this, or the division of work is such that you have the ability to segment your work this way, then this particular methodology works.
For what it’s worth, it’s probably not something I would suggest for something over, say, a three-person team nor is it something I recommend doing if your areas of responsibilities bleed over into one another.
But if it’s just two or three of you, you’re distributed, and you’ve got extremely strict lines of responsibility, then this is one way in which you all can continue to work without bottlenecking one another’s work.