This article is excerpted from our recently published book "Jump Start PHP Environment", which is available for free by SitePoint Premium members. Paper versions and e-books are available in major bookstores around the world, and you can also order them here. Hope you enjoyed this excerpt and found it useful.
We will focus on the application environment. We will also discuss *AMP bundles like XAMPP and why they are a bad choice; production/development consistency; and performance and debugging.
Application environment refers to the environment in which an application may exist at various stages of its life cycle: production environment, development environment, and pre-release environment.
The term environment refers to the hardware and software around an application; that is, everything used to power it.
We will start with the simplest environment: the production environment.
When you deploy an application—in other words, upload it to the server and make it publicly accessible to the target audience—you are putting it into production or using
. The production environment is the ultimate destination for your application and the purpose of your code. In the life cycle of an application, the production environment is a real-time server—a server computer whose settings allow others to connect to it and view your website. This live server will be configured to serve your application as efficiently as possible. All the extra files you use during the development process will be removed from the application through a process called compilation or build, which will be explained further later.In a production environment, your website is considered real-time (or deployed) and can be accessed through its own domain name; for example, https://www.php.cn/link/52eea859b07495d44fb844cdcecdf239 .
This is equivalent to a chef cooking in a restaurant and delivering the food to the customers who ordered it.
In a development environment, your application is under active development. A development environment is the computer you use as a developer to develop applications, including the computers of all your team members, whether they are near you or remotely. It should be noted that although these two aspects are covered, the development environment refers more to the state of your application than its physical location - the application is in In development status. In a development environment, you can use a variety of tools—from the IDE (see Chapter 2) to unit test libraries and standard fixes, compilers and builders, file monitors, and more—anything you need to complete Something to work on hand.
If we compare our application to a smartphone, the assembly plant that makes it is the development environment. This environment contains all the necessary components—screen, housing, battery, various LEDs—and each component is tested separately before it is used to build a smartphone unit. This is called unit testing – making sure every unit works.
For examples of unit testing in application development, see the section titled "For those who want more" at the end of this chapter.
To further illustrate the metaphor of smartphone assembly, the battery being tested may require a separate charger accessory, or may require a robotic arm with synthetic fingers to test the screen to ensure the touch sensitivity of the screen is working properly.
All of these add-ons exist only during development. These add-ons are removed when you convert from a development environment to a production environment (also known as Deploy 
). For our application, this means the aforementioned compilation/build steps: various CSS and JavaScript files are merged and scaled down to reduce the size of the website and make it appear faster when people visit; unit tests are Ignore and stay in the development environment; and various other optimizations occur (introduced later in this chapter) – all to maximize the appeal and potential of the final product when it is declared ready.
Hosts and Virtual Hosts
. In short, the virtual host issues instructions to the server program installed on your computer, for example: If the user requests http://mysite.com in the browser, run the file mysite.php through PHP and browse Its output is displayed in the machine.
As you can see, this is almost the same as the regular request process for a live website. But what makes the browser ask the mysite.com domain name to the server program of our own computer instead of looking for it on the name server of the internet? Host file.
Host files are special files that exist on each operating system. We briefly mentioned it in the section 1 titled “For those who want more”. It contains a list of the domain name and its corresponding IP address so that any browser on your computer can read it and go directly to the IP address without having to communicate with the DNS to check where you want to go. On Windows, the file is located in C:WindowsSystem32driveversetchosts, on Linux and Mac machines, it is located in /etc/hosts. If you put an IP-name pair into this file, the computer will obey it. We can try it now. Don't be afraid - nothing goes wrong. Ready?
On Windows, enter the search field, type "Notepad", and when it appears, right-click it and select "Run as Administrator". You will then be asked to confirm. In the window that opens, select "File" > "Open", and then go to: My Computer >C: >Windows >System32>drivers>etc. In the lower right corner of the Notepad window, you may want to select "All Files" to display the hosts file. Double-click to open it.
On Linux/Mac machine, open the terminal by searching.On Linux, open the default text editor as an administrator by typing sudo gedit in the terminal. You will be asked to enter the administrator password. On OS X, enter sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit, which will perform the same task. In either of these two editors, go to "File" -> "Open" and enter the directory /etc to find the hosts file. Double-click to open it. After opening the file, note the first few lines: they all start with a hash symbol (#). This means that they are comments and have no effect on the file. These are used to explain files to users and they are also present in PHP.
Now, under all these comment lines, add the following line:
Save the file and open http://bing.com in your browser. You have just successfully redirected all requests to Microsoft search engine Bing to Google! Of course, we don't want to keep these changes; you can feel free to delete this line or put a hash symbol before it to convert it to a comment and save the file. You should be able to visit http://bing.com again as usual.
<code>208.117.229.217 bing.com</code>
Using this method, we later redirect all browser requests to http://mysite.com (which will be the sample domain name of our application) to our own computer's server. This will allow us to easily test the development version of our website without deploying it to a real-time environment.
A pre-release environment is a separate server (or multiple servers) that contains a copy of the production environment (also known as a mirror). In small companies or projects, pre-release environments are usually skipped. It is designed to be as similar to the production environment as possible, with the installed software version matching, the configuration values are the same, and so on. Pre-release is used to perform final tests; for example, Facebook might redesign its homepage, and it will deploy it to its pre-release server for employees (also known as quality assurance) before deploying it to a production environment for all users to view. A dedicated non-programmer for the team) can test everything first as if it were regularly used. If everything goes well, a final deployment from pre-release to production will occur.
Pre-release is beyond the scope of this book, but it is always good to know it. In the age of virtual machines and small one-time projects, pre-releases can be redundant and will only work in larger, long-term web applications.
In this context, we must also introduce the maintenance mode. It is a mode , not a environment because the environment around the application will not change - only the state of the application will change. It is usually just a switch on the production server that tells people trying to visit the site something like "come back now, adjusting!"
When starting PHP development, it is very tempting to download and install packages such as XAMPP, WAMP, MAMP or EasyPHP. AMP in these names stands for "Apache, MySQL, and PHP". XAMPP adds another P at the end for Perl language. The first letter refers to the operating system: Windows, Linux, Mac OS X, or in the case of XAMPP, cross-platform (meaning it can run on any operating system).
These bundles contain all the software you need to run PHP applications quickly and easily on your computer. With just one click, you can install everything you need to write your first PHP script. So, what are the disadvantages?
Let's solve these problems one by one.
Whenever you install software like *AMP stack on your computer, a part of your computer will be damaged. Even if you delete the software later, it usually leaves a discomfortable trace—usually in the form of a registry key in Windows or a residue of a file on Linux. In fact, this is especially noticeable on Linux. While Windows and OS X applications are installed in one application folder, all related files are included, on Linux, installing software is like shooting a castle built with a shotgun. With one click, they are everywhere. Over time, you will install another library, another package, another tool. As you further develop your application, you will continue to add supplemental software, maybe adding completely different projects, as you have already started working on a new project in parallel. Maybe app1 needs a PHP extension to edit images, while app2 needs a PHP extension to allow it to package the code into a closed source archive so that your code is hidden from competitors . Over time, you will have hundreds of megabytes of development software on your machine, but don't know if you still need it. Your machine will slow down, your application will become less usable, and your development machine – the computer you are using – will be so different from the production server on which you end up planning to deploy your application, that You won't be able to handle this difference gracefully. You will end up fighting mistakes on a live website often and annoy your visitors. By relying on these prebuilt packages, you will also deprive yourself of learning system management (ops for short). In larger companies, Ops is a team or person in charge of server issues—whether it is fixing errors, installing new software, upgrading existing software, and more. Basic system management is a must-have skill when working on smaller teams or alone for clients. While it is very convenient to be able to install everything you need on your computer with one click, there is no user interface on the server and therefore cannot be clicked; you need to master the commands you need to set up the server software so that it can run your PHP application . Otherwise, you are either destined to hire a server administrator to help you, or worse, use a shared hosting (a horror story explained in Chapter 6). By refusing to rely on these *AMP bundles, you will be forced to manually install servers and other software, which will force you to overcome the learning curve – if you take this career path seriously, this knowledge will be used to you in many ways Helpful. Also, it’s not actually difficult to master the basics, as you’ll see later in this book. Suppose app1 and app2 are built on PHP 5.3, run MySQL 4.0, and are intended to be deployed on a server powered by Apache (server software). Then, there is a new requirement: make sure app1 can run on PHP 5.6 and MySQL 5.1 and can be driven by Nginx (another server program competing with Apache, pronounced "engine x"). Oh, what should I do now? We can update PHP to a newer version and check if app1 is still valid, but how can we continue to develop app2 without unexpectedly using code that is not available in PHP 5.3 What about
Lastly, what if we try to install a new version of PHP but there is a problem? This situation is especially common in OS X and Linux - the PHP versions installed on our machines are now not working, and it turns out that it is impossible to get a single site to run. What a mess! Rather than being able to easily restore to the previous running state, we were forced to spend a whole day debugging our own system and trying to get it running – not necessarily the right version, but just run
The best way to achieve consistency is to run the exact same software in your development environment as in your production environment. For example, if you intend to deploy your application to a production environment on a server running the Ubuntu Linux 14.04 operating system, it is best to develop on this operating system as well. But what if we are running Windows because we like to use advanced multimedia content like games, or we need some powerful image and video processing software that doesn't exist at all on the Linux operating system? Should we abandon all our other interests, install Linux on Windows, and work on consistency rather than anything else? Or should we give up consistency and take risks while keeping our computers strong, beautiful and stable, sticking to the operating system of our choice? Luckily, there is a third way to get the best of both worlds at the same time: a virtual machine (introduced in Chapter 4). The last few aspects of the application environment we need to introduce are ensuring that the application is fast (performance) and error-free (debug). This section is completely theoretical; just to let you know what to expect later when you encounter these terms. Performance is achieved through various optimization methods. Contrary to the meaning of the word, in application development, optimization usually has multiple levels, and few changes immediately lead to a perfect solution. Performance includes but is not limited to the following aspects: Learning is progress, or how comfort zone is overestimated
Test
Clutter that cannot be cleaned
Production/development consistencyPerformance and debugging
So, how to measure performance or find errors? There are a lot of tools that can be used to analyze PHP applications (this is what is called finding errors and measuring performance in every aspect of the application). Two better tools are Z-Ray and Blackfire (we won't introduce them in this book because they are beyond the scope of this book).
It should be noted that a common beginner mistake is micro-optimization. For example, there was once a thought that using single quotes with strings ($var = 'Some String') is faster than double quotes ($var = "Some String"). The performance gains this optimization can lead to are negligible and almost always trivial; on the contrary, improving complex SQL queries or caching remote HTTP calls will always be an order of magnitude larger. If in doubt, use benchmarks and real data (such as data from Z-Ray or Blackfire) and never use your intuition.
In this chapter, we explore application environments, covering various ecosystems that exist around an application at a given stage of its life cycle. We discussed virtual hosting and how to configure your computer to redirect the website URL to your own PHP installation instead of finding results online, and we discussed very important development/production consistency.
If this all seems too complicated, don't be discouraged. This is simply because so far we have dealt with almost only theory – theories necessary to bravely enter the realm of practice. In the next chapter, we will use some virtual machines to operate it yourself.
In the application realm, testing individual components is called unit tests—testing each individual set of code so that you know if it works.
For example, a part of your application may have the ability to remove local symbols from each name and convert them to American-friendly letters. My last name "Škvorc" will therefore be converted to "Skvorc". Converting Škvorc to Skvorc is a small piece of code, or a unit. This unit is testable; that is, for any given "Škvorc" input, I expect the output of "Skvorc". I can then write a unit test, which is a file that defines the input and the required output, and when I run it, it tests if this function is still valid. If two months later I changed something in the app, I could easily run this test (still exist) and check if this conversion is still valid. This workflow ensures that you can upgrade your application later without worrying about breaking what you have built and forgotten before. In our metaphor about smartphones at the beginning of this chapter, a separate testable unit can be a touch screen or a battery.
PHP application environment is an important aspect of web development. It provides a controlled environment where developers can build, test, and deploy their PHP applications. This environment includes a PHP interpreter, a web server, and a database system. It allows developers to manage different aspects of the application in a consistent and predictable way, such as configuration settings, error handling, and database connections. This leads to more efficient development processes and higher quality applications.
PHP application environment is designed for web development. They are equipped with the ability to facilitate the creation of dynamic web pages and web applications. Unlike some other programming environments, the PHP environment supports various databases and is compatible with various operating systems. They also offer a wide range of error reporting and logging capabilities, which can greatly aid in debugging and troubleshooting.
PHP application environment usually contains three main components: PHP interpreter, web server, and database system. The PHP interpreter is responsible for executing PHP scripts. The web server handles HTTP requests and responses. The database system stores and retrieves data according to the requirements of PHP applications. Together, these components provide a comprehensive platform for the development, testing and deployment of PHP applications.
Setting up the PHP application environment includes installing and configuring the necessary components. This includes PHP interpreters, web servers (such as Apache or Nginx) and database systems (such as MySQL or PostgreSQL). After installing these components, they need to be configured to work together. This may include setting up a database connection, configuring PHP settings, and setting up a web server to handle PHP scripts.
Best practices for managing PHP application environments include keeping the environment up to date, backing up data regularly, and monitoring the performance of the environment. It is also important to follow security best practices, such as using secure connections, protecting sensitive data, and regularly checking for vulnerabilities. Additionally, using a version control system can help manage changes and track different versions of your application.
PHP application environment provides a wide range of error reporting and logging capabilities. These features can be configured to provide detailed information about errors that occur during execution of PHP scripts. This information is invaluable for debugging and troubleshooting. Additionally, the PHP environment can be set to handle errors in a way that does not interrupt the user experience, for example by displaying a custom error page.
Yes, the PHP application environment can be used for mobile application development. PHP is a server-side scripting language, which means it can be used to create backends for mobile applications. This backend can handle tasks such as processing data, interacting with databases, and managing user sessions. However, for the front end of a mobile application, you usually use different technologies such as HTML, CSS, and JavaScript.
There are many advantages to using a PHP application environment. It provides a controlled and predictable environment for developing, testing, and deploying PHP applications. It supports a variety of databases and is compatible with various operating systems. It also offers a wide range of error reporting and logging capabilities, which can greatly aid in debugging and troubleshooting. Additionally, PHP environments are usually easy to set up and manage.
Protecting the PHP application environment involves multiple steps. This includes using secure connections, protecting sensitive data, regularly updating the environment, and checking for vulnerabilities. It is also important to follow best practices for PHP encoding, such as validating and cleaning user input, using preprocessing statements for database queries, and avoiding deprecated functions.
Yes, the PHP application environment can be customized to meet the specific needs of the project. This may include configuring PHP settings, setting up database connections, and customizing the web server. In addition, there are many available tools and libraries that can extend the functionality of the PHP environment, such as frameworks for rapid application development, testing tools, and libraries for handling tasks such as image processing, XML parsing, etc.
The above is the detailed content of The PHP Application Environment. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
