Join Jon Peck for an in-depth discussion in this video Where should I be developing?, part of Learning Linux for PHP Developers (2014).
Engineers are faced with many technical challenges across projects. Not only do we have to deliver a functional product, but we also need a place to build and test as well. Where should development take place? The solution is known as a development environment, which is a working environment for software developers. A development environment contains the tools in order to write, execute, and debug software. A proper dev environment is isolated from other environments. This means it's not visible or accessible by the public, and any code changes made in the environment do not affect the rest of the team.
In that sense, dev environments are optimized for experimentation and building of new features. So, how does this practically apply to PHP developers and the web? Well, web development refers to the tasks associated with creating a website, anywhere from a simple static page to complex applications. There are a couple tasks that are most commonly performed in dev environments. Programming of the functional aspects of an application is best done away from the public to avoid errors and security problems. In a similar fashion, the design of the look and feel of a website is another crucial component.
A site needs to be useable, not just functional. Finally, the testing of the functionality and performance in dev environments avoids potential impact on a live site, especially if the task finds a problem. Within this context, web applications are a bit more complex than static pages. Web applications have three primary components. The client is used to interact with the application, and in most cases is a web browser like Firefox or Chrome. The web server delivers content on the Internet such as static files like images and style sheets.
Web applications also require an interpreter to execute scripts written in languages like PHP. Finally, persistent data is handled with a database management system that stores and retrieves data. MySQL is a popular DBMS, and we'll explore it and some alternatives later on. So what are some of the ways that a developer can get a web server and a DBMS? The first option are web hosting services, which provide space on a server along with internet connectivity. Typically, they'll manage the server configuration, so all you have to do is provide the application and the data, and you just use their configuration, whatever it may be.
Of course, this isn't free. You are paying to delegate responsibility, which isn't always a bad thing. Feel like you can handle hosting yourself? Self hosting is always an option. The primary advantage is that it lowers cost to third parties. It's also a lot more flexible in that you can basically configure your components however you want it. However, this incurs greater costs to yourself in the forms of overhead of maintenance and management, and also requires expertise if you wanted to keep it secure, fast, and clean.
While it's a valid option, there's a lot of hidden costs. So, is there a way to keep it cheap and flexible? Locally hosting can be the best of both worlds, where you can have a full web application on your local computer or work station. Instead of being public, locally-hosted content is only visible to yourself, which has its advantages and disadvantages. Since it's local, you are the one who's responsible for managing the components, which gives you ultimate flexibility. Unlike other hosting options, there's very low overhead and the additional cost is basically none.
For these reasons, locally hosting an application makes it an excellent option for development. There are a number of reasons why local development is a great option. First of all, it's fast since every service is on the same machine, so there's no network latency between you and the servers. It's also an unshared resource, so as long as you're not doing anything goofy in the background, your application will run as fast as it can. Local development can be really flexible in that you can configure it to your needs. Want a particular version of a server? Install it.
You can also work without the internet, which is great for travel or even just getting out of the office. To that end, local development can be very portable, especially given that modern laptops have more than enough capabilities to be a great solution. In fact, I use laptops for pretty much all my work these days. Finally, local development is inexpensive, given that you already have the hardware. You don't have to buy or manage more equipment to be able to host locally. Is there any reason why development locally wouldn't be optimal? Let's look at this question from another perspective.
Why develop remotely? Well, platform uniformity is actually really important, meaning having the same versions installed and a common configuration across components. Ever hear or use the excuse that it worked on development, but not in any other environment? Yeah, it's pretty annoying. Remote development can also make security and management easier through controlled access to the data and code. You're a lot less likely to leave a server on a subway than you are on your laptop. Speed of deployment is also a factor. If everything is centrally located, then there's less to transfer and synchronize.
For projects with gigabytes or terabytes of data, deployment speed becomes extremely important. Kind of sobering when you think about it. So, is there no way to compensate? A lot can be done to mitigate the risks of local development. Starting with physical security, you can restrict account access with a good password scheme or options like two-factor authentication. You can also encrypt your hard drive, which will render it useless if your computer is stolen. Making a point to store only what's required for development and nothing else reduces the potential collateral damage in case of a breach.
If you have all your data locally, it can be a single point of failure in the event of a catastrophic event like a fire, theft, or even just component failure. Remote backups will save the day as long as you can make, maintain, and access them quickly. Finally, configuration management is one of those problems that can be solved with a documentation of what components are needed. It's best to use the same tools and techniques across your entire team and environments, which will minimize the need for variation. The closer you can get to mirroring the production environment's configuration, the better.
At the end of the day, the question that you are in the best position to answer is, what's right for your project. There's no one right answer. It's best to know what your options are and I've presented a few already. You should weigh the benefits and risks of any approach that you'd like to take because it may be worth a higher upfront cost to reduce overhead later on. Even if you're enthusiastic about trying something new, make sure you have the consensus of the team that you're working with. Help make decisions that are best for the group, not for the individual. Trust me, exceptions slow everybody down.
No matter what approach you take, you should focus on building something great that you could be proud of. How you do that is up to you.
The demonstrations are performed with the Ubuntu LTS distribution of Linux, but the skills taught here are also applicable to other Linux distributions. Every command is described in detail in context, and a comprehensive quick reference is provided for convenience.
- What is Linux, and why should I use it?
- What's a LAMP, and why does it matter?
- Creating and configuring a virtual machine
- Working with the Linux command line
- Configuring the servers, including Apache virtual hosts
- Building a development server dashboard
- Using PHP package managers like Composer and PEAR
- Installing Drupal, WordPress, and more on the server
- Self-hosting Git repositories, including a web interface
- Enhancing the server with debugging and profiling
- Exporting a virtual appliance to use on another machine
- Server troubleshooting techniques
Skill Level Beginner
Q: The pecl installation of uploadprogress fails, saying it is not a valid package archive. How can I install uploadprogress?
A: There is a bug in Ubuntu's pecl that was introduced after the course was recorded; the workaround command is "sudo pecl install -Z uploadprogress"
Q: Where can I get the exact versions of the software used in this course?
Q: In Windows, git operations ask for a password. Why?
A: Make sure that pagent (PuTTY agent) is running and has the private key loaded. See Chapter 3, movie 4 for details.