After working with Coda/Coda 2 and FTP for a few years, it was time to make a workflow upgrade. Don’t get me wrong, Coda 2 is pretty amazing: my main Coda 2 window was fully customized to my liking, all my sites were organized, connecting to web servers was a breeze with FTP built-in and I had amassed a robust collection of snippets (err, “Clips” in Coda) that served me well. And no, I was not “going commando” as Chris Coyier laments against — that is, working on the remote files directly. I always work on local versions of the file(s), do any precompiling of my Sass/SCSS in CodeKit and then would publish to the server in Coda 2 with a simple key command (see tip below). I used Tower for version control with GitHub and everything was fine and dandy.
But it wasn’t. For one, even though my Coda 2/CodeKit workflow was pretty fast, I was still using the mouse (or trackpad as it were) way too much. All these little movements add up to hours and hours of wasted time. In addition, I knew I wasn’t really using Git/GitHub properly. Yes, changes were being tracked, commits were being made and version control certainly saved my ass a few times but I knew there was way more to it. What’s more, I was starting to get more into actual coding and needed a proper development environment that could make things easier and faster.
My requirements were as follows:
- do everything I could do in Coda 2: FTP, code snippets, command line
- publish to GitHub and to either a production or live server simultaneously
- have a properly set up development environment to start running code locally (like node.js)
Changes (and major ones) would have to be made but I was ready. I knew there would be a lot to learn but I was ready for that too.
Enter Sublime Text 3
Sublime Text 2 was not completely foreign to me — I had used it a few times but never really delved in fully until recently. This seemed like the perfect time to check it out in more detail. After spending a couple days with Sublime Text 3 and watching this great tutorial by Jeffrey Way at Tuts+, I finally got my head around it. Holy Package Control! All of the things! I was hooked.
ST3 is just so powerful it’s mindblowing. With just a few plugins added through Package Control I’m already typing about half as much and that’s just scratching the surface. There are so many things I wasn’t using with Coda 2 that are simply indispensable to me now: Emmet (previously Zen Coding), Fetch, superior snippet integration, amazing Git support, Xiki — the list goes on. In ST3 these aren’t just bells and whistles but tools that help you to not only code faster but code better. Just going through the process of getting ST3 set up changes the way you use your computer for other things.
Super Pro Workflow
Next it was time to set up Git + GitHub as well as my deployment location on the server so that I could keep everything in sync and do it all from ST3. This is assuming you have MAMP setup on your local machine and using WordPress.
Here are the steps:
- Set up RSA key authentication on GitHub. From your account, go to Account Settings > Applications > Personal Access Token > Create new token.
- Get SublimeGit with Package Control.
- Create new local repo:
- Make your first commit:
git commit -m "first commit"
- Set up your github remote repo:
git remote add origin https://github.com/joshuaiz/joshuaiz.git
- Push your local repo to GitHub:
git push -u remote origin master
- Then SSH to your web server location (in my case DreamHost)
- Clone your repo:
git clone git://github.com/joshuaiz/joshuaiz.git
- Your site is now deployed!
- Keeping it in sync is simple. In the git working directory on your web server, just create a php file with the following:
<?php `git pull`;
- Then go to your repo on GitHub: http://github.com/youraccount/yourrepo.git > Settings > Webhooks & Services > Add Webhook and create a web hook with the URL to the php file you created in the previous step: http://yoursite.com/wp-content/themes/yourtheme/github.php. Now, whenever you push to your repo, GitHub will send a POST request to that file location which will keep your web server in perfect sync! Sweetness.
More info about these steps here. There are lots of other deployment scripts out there with all kinds of configuration options but you really don’t need any of those. The
git pull file (in backtics) is a git command within a php file and that’s all you really need to keep everything updated. Jeffery Way also mentions this in his Sublime Text tutorial. Note that you can do all of the Git steps from within ST3 using SublimeGit.
You might be saying what’s the big deal here? In short, this changes everything.
Here was my workflow before:
- Install WordPress on a remote test domain
- Copy base theme files over using my fork of Bones – Osseous by dragging in Coda 2
- Drag files back to my local Sites/mysite/ folder
- Create local repo
- Create remote repo on GitHub
- Work on local files in Coda 2. Use CodeKit workaround (see below) for Coda 2 to see changed compiled Sass/SCSS files
- Publish to server with key command
- Switch from Coda 2 to browser; refresh browser
- Make changes in Chrome Dev Tools
- Copy changes in Chrome, update local files
- Rinse, repeat
- Use Tower to push changes to GitHub
- Set up local and GitHub remote repos
- Set up MAMP to work on files locally
- Add project to CodeKit (no workaround necessary). Set CodeKit to refresh local browser on save
- Work on local files
- Switch to browser and back to ST3 with Command-Tab (switch applications)
- Once ready to deploy, start from step 7 above
- Continue to work locally, push commits to GitHub using SublimeGit and use SyncDB with Xiki within ST3 (see below) and everything is synced: content, database, plugins, everything.
BOOM! This is so much faster. Just working locally saves so much time as your pages refresh pretty much instantly instead of waiting for a live server to reload. Again. And again.
Content: Just started playing around with this SyncDB script which can upload your local db to your web server and then automatically find/replace your local/live URLs. It also syncs your /uploads folder using
rsync. When configured, you can upload and replace your WP db with a single command in Terminal:
./syncdb push or
pull to sync down. Absolutely amazing. If you’ve used the fantastic Interconnectit db search and replace script, SyncDB has this built in. What’s more, you can create a Xiki Buffer and run syncdb right from within ST3! This is a game changer.
After working with this system for a few short days I could not be happier. I’ll still use Coda 2 for quick updates of old projects but moving forward I will be using ST3 for everything. I’m sure there will be some tweaks so I’ll post an update in a few weeks.
Now, if only I could settle on one of the many custom Sublime Text themes available, I may end up actually getting some work done. Speaking of which, if you’d like to create your own ST2/3 theme, here’s a handy little Chrome app: http://tmtheme-editor.herokuapp.com/. It’s a little buggy and freezes up on occasion but it’s fun to play around with. I’ve created a few derivitive themes and I’m getting closer to a perfect one.
Tip: Getting Coda 2 to see changes in your CodeKit compiled files
While Coda 2 + CodeKit work well together, Coda 2 doesn’t recognize out of the box that CodeKit compiled files (for example Sass/LESS) have been changed and thus does not mark them as ready to be published. There is a workaround however:
Navigate to your compiled files in Finder. In my case it was style.css and ie.css. Right-click on each CodeKit compiled file to show the contextual menu and go to Open With… Here you want to select CodeKit — it may not be in the menu so if not go down to “Other…”. Navigate to /Applications/CodeKit.app and select it. CodeKit will give you a warning saying the file is already part of a project — just click OK. Do this for each compiled file and then Coda 2 will now see them as changed and ready to be published. In Coda 2 you can use Shift-Command-P to publish all changed files in one go. See image below to see the contextual menu for selecting the CodeKit app.