Today I learned:

Proper development infrastructure

When doing development work, it is best if you have a separate, dedicated area for each of these things:

• Development – The area where you do your development work.
• Staging – The area where you deploy changes and thoroughly test them. The only thing that should be out of sync with the production environment is the single change you are testing.
• Production – The live system for stable, tested code.

I’ve attempted to replicate this best-practice with the development of my Toggl slash command for Slack. My development environment is on a Homestead box on my local machine. The staging area is a folder on my dev server that a /toggldev command posts to. Once the changes here have been confirmed, I commit my code to the repository and then deploy it to production. The production environment is a folder on my main server that the /toggl command posts to. This is the one my team uses and it stays up to date with releases in the repository.

Of course, the entire process is better if you have version control:

A method for committing changes in Git

Eric Davis advises me that it is better form to commit changes after each feature you want to release is completed rather than commit after a full day of work. If you don’t commit after each feature (and develop each feature in a separate branch), you’ll end up with a mass of code changes in each commit that is about as tangled as spaghetti.

Right now, since I’m the only one working on my Toggl project and the changes I’m making aren’t major, I’ve only been working directly on the master branch. This Atlassian tutorial on branches has convinced me that I should be using branches on a daily basis for development, so I’m going to start that this weekend with some new features I plan to work on.