Development Environments

Development Environments

Setting up proper development environments is an important step in the web application development process. Having consistent environments will reduce errors in deployments, allow your team to use their preferred tool and workflow, and save your developers a lot of headaches. In return, this will all reduce some of the fighting and bickering surrounding operating system superiority.

With websites becoming more complicated, the same goes for the web development process. You can’t build Facebook with HTML! Development projects often take many developers and iterations before perfection. The first step in any large project is considering your development environment. Usually, every developer has their own tools and styles of working—and maybe their own way of brewing coffee—but your goal is to make sure your developers can code and work harmoniously. Once you pick a decent development environment and workflow, everything else falls into line and your developers can work together, regardless of their feelings about Mac vs Windows.

A proper application environment process should include several tiers, with all changes being moved upstream. At Lucid Agency, we try to stick to at least three to four tiers depending on how large or challenging the project is. Our typical setup is Local -> Dev -> Staging -> Production/Live. Each tier will have an associated branch in version control. Every developer working on the project will have his or her own local or feature branch that is then pulled to Dev. Dev is where we test on our end, making sure features don’t conflict or cause errors as they are built. When it is ready for the client it will be pushed to the staging environment for their final approval. Last but not least, we make the now slightly less terrifying push to live. The process always moves upstream so we can keep clean and error free environments.

A common development process involves stages of development. Just like a car goes fromgit-large-imge prototype to model to the car sales lot, code goes through the same types of stages. Lucid Agency uses a process with Git (a type of source code management) that works as follows:


The developer makes changes on their local machine. These types of changes are like the first draft in a paper. Once the first draft of the paper is approved, it goes to the Development stage.


This stage begins when the team tests its functionality and aesthetics, and works to debug problems. During this stage, the developers collaborate to find the best way to improve the project. The project can range from developing a website to a new iPhone app. After the developers agree the project is complete in the Development stage, they take this “draft” of the project to the next level: Staging.


Staging has a pretty self-explanatory name; it’s where we put the code on stage for everyone involved in the project to see. This can be anywhere from internal quality assurance testers, to project managers, to the client. If any changes are requested, they are done on Development stage and the process starts over. Just like actors, we don’t make changes in the middle of our play. We go back to rehearsal and make changes before our next debut.


If everything goes well in Staging, the code goes live after rigorous testing. No changes are made on production for the same reason that no changes are made on staging— it’s messy— and some changes will be missed for the next round. More importantly, no changes are ever done in production because it might cause downtime for the client and that’s a big no-no.



Setting up your development utopia doesn’t have to be a lengthy process. There are plenty of technologies that can help you along the way:

Vagrant uses virtual machines for the environment and provisioning tools to install all vagrant_logodependencies needed. The best part is after Vagrant is installed and configured, it can run in a two word command— “vagrant up.” There are also a wide variety of Vagrant “boxes” that are packaged environments ready to go.

Currently, my favorite box is Laravel Homestead. It was originally made for easy Laravel development, but I use for most of my local development. It’s as simple as adding and installing the Homestead Vagrant box, adding your SSH key, and editing the site configuration file. Easy SSH access, one line serve command for creating additional sites, and vagrant functionality to share environments make this an easy to use setup for someone who doesn’t want to build a box from scratch.

For pushibitbucketng code changes upstream, we prefer to use version control, Git in our case, with remotes setup to pull in their associated branch relative to their environment. Github is kind enough to provide hooks so that once we push a commit to a branch, our remotes can pull in the fresh code.


For our version control there are many choices such as SVN and Bitbucket, but the most popular choice and the easiest is Git, which works in conjunction with Github. With awesome support and lots of documentation, it’s the easiest choice for newcomers and hardened developers alike.

Using development environments correctly is a vital piece of the software or web development workflow. There are many tools and processes out there, so pick the right one for your team and get working!

[email protected]

Christine is the Communication Director at Lucid Agency, with a focus on internal communication and public relations. Christine is a proud ASU alumnus with B.S. in Marketing from W.P. Carey School of Business and a minor in Art History from the Herberger Institute of Design and the Arts. She enjoys combining the varied natures and influences of her education in her work and loves to debate word choice on the merits of connotation VS denotation, if anyone wants to take her up on it.

No Comments

Sorry, the comment form is closed at this time.