Daniel Ahrendt

Developing with Haystack: A Day in the Life

Developing with Haystack: A Day in the Life

As a developer at GoSolid, I've experienced my fair share of development environment strategies over the last 4 years. Hours of productivity could be lost in a configuration battlefield, or collectively vanish from sluggish mounting processes. However, over the last 6 months, I've been able to utilize the prototype of the Haystack CLI, significantly improving my day of deving.

To illustrate just how useful the Haystack CLI can be, let’s run through a general project setup for me, a typical agency web developer.

Setting Up a New Environment

A client (let’s call them Acme) who runs a Magento 2 site wants a new feature and it's time to build. I currently have no development environment set up for them. So I checkout my branch:

git checkout feature-branch-1

It already has the Haystack file in it, so I just need to:

hs start -i dev-acme

Then I get a quick mode question:

Which mode would you like to run in?
1) Local
2) Haystack Cloud
3) AWS (team account provider)

I enter

3

and we're off to the races; my box is building.

Stack is being created. Use the $hs status option to view that status..

A minute later, I run

hs status

to check the status of my new box. The command returns a grid of my running instances with the unique identifier, state, IP, domain name, and created at time for each.

I can see that my new box has the unique identifier I named it, dev-acme and that the domain name is dev-acme.build.gosolid.io. It is currently running according to the instance's state. All I have to do is visit http://dev-acme.build.gosolid.io in my web browser and ta-dah, I have a fully functional development environment for Acme's Magento 2 site, utilizing my local code.

Developing on the Box

Unless I tell it not to mount on start, Haystack will connect my local filesystem to the local or cloud stack.

Mounted to instance 'dev-acme'. Happy coding!

Now I can modify code on my local machine, and it will automatically change the application.

Sharing the Work

Let's say I'm working on the feature and would like a second opinion on my implementation from someone else. Instead of sending screenshots or uploading my feature to a test stage for a co-worker to review, I provide them with my instance's domain name, http://dev-acme.build.gosolid.io. That's all there is to it.

SSH

Say I need to ssh into the instance itself. In order to do this, I run the following (when in the same directory as my Haystack file)

hs ssh

This opens a new terminal window straight into my application.

Since private keys are automatically shared among authenticated team members, if a team member wants to access my instance, they can run another command to SSH into the my environment.

hs ssh -i dev-acme

Disposability

While SSHed into my instance at it's root, I accidentally run

rm -rf /var

Oops. What now?

Fortunately, I've already committed and pushed my work, so I can run the following to terminate the instance.

hs rm

In less than a minute, the instance is gone. All I have to do after that is spin up another box, putting me back where I was just a few minutes ago, fully recovered from my traumatic blunder.

In conclusion, the amount of time it takes to set up development environments through Vagrant—let alone LAMP—compared to Haystack is a thought I'd rather not entertain. The benefits of Haystack dramatically change my day to day development experience. Spinning up and terminating varied environments in a matter of minutes? Direct and easy collaboration with co-workers from anywhere?

At this point, I find returning to past development environment strategies inconceivable. Each codebase I work on is fully contained, isolated in its own infinitely and easily replicable environment.