What did you do to improve development in php?

Question

PHP

The customer has a fairly visited site, the codeigniter framework is used, the code is uploaded to php or edited immediately via ssh on the server from under the root. Actually, there are a lot of problems with development from the fact that the necessary things are not being done, there is no control over the source codes, an old fired programmer shat in the code, sometimes the site crashes when updating the code, developers make a huge number of errors.

The first thing I did was migrate the site to a new machine with the latest versions of php and apache, blocked ssh access, gave ftp access, cleaned out the malicious code (not sure if it was all), fixed all the small errors that came out after updating php from 5.1 to 5.3, with the base mysql now work from under a separate account not from under the root one. I’ll immediately note that a lot of people developed and the code is more like redneck code, it was not easy to figure out some of the errors, the code is filled with a bunch of comments with debug code.

I think we still need to make a test server for running the changes, transfer the sources to github, and transfer the development roadmap from Excel there. Deploy everything to the site with a git, first to a test site, and then to production.

What else can be done? How do you develop for production in php?

Answer 1

Testing + documentation can still be screwed. Well, all this through some kind of continuous integration server.
A test server (well, or staging), I think, is a must.

Answer 2

1) Test server
Very often there are situations when a developer (in particular, a freelancer) is not at his favorite workplace, but somewhere away, away, etc.
When it becomes necessary to fix a bug or make any changes - deploy all the tools behind someone's laptop / stationary, install denver, download the whole thing, deploy the base. It is much easier to install winscp¬epad++ and make edits for production. With an increase in the frequency of such “edits”, the code turns into what is described above.
To solve such problems, first of all, a regulation was introduced - a ban on making changes to production, but! at the same time, work on a test server is allowed! All edits, small and large ones from the server are committed to svn (learning the svn console commands for a developer is not a problem ... they need 2-3 in such a situation) and only after that an update on production. For the production update, there is even a www-script that allows you to update without connecting to ssh, etc.
Changes in the database are all only through migrations!
So make a test server for sure! IMHO a necessary thing for any project.
2) Tracker! Writing and communicating through the tracker educates both the client and the customer.
We deployed redmine on the same test site. Later, a tikiwiki was added to it, in which useful little things are written for other developers and the client. The tracker also displays developer activity for the client. The client is pleased to see that there was such an error and such and such a commit was made to correct it and something was changed.
3) Carrying out refactoring. It is very difficult to explain to the client what it is and why it is needed. Why should he pay to "rewrite" the code? Write right away, he says. Practice shows that all the same it is possible to prove to the client the necessity of this action.
4) Automatic tests.
On a test server, it is far from always possible to see all the problems - whether someone else's code has broken.
The use of frameworks allows you not to breed total bullshit and impose tests on the code.

Answer 3

Depends on the project. Unit tests (I suspect that they don’t exist), Continuous Integration,… By the way, does the customer mind having sources on github? Or are you going to create a private repository?

Answer 4

Now I'll give you some useless advice.
My last refinement led to a rewrite from scratch. The profit is huge - if you write right away according to the plan and correctly, it turns out quickly, 500 lines of code can be rolled into 10 lines of the controller / model in MVC.

Answer 5

Some advice from the person who ate the dog on CodeIgniter.
CodeIgniter has very good extensibility, analyze the code, find common points and refactor the code, move common methods from models to your model types (you can inherit from MY_Model), with controllers the same.
Views files are hopefully divided into controller folders, if not, then you need to split them. All JS should also be placed in a separate folder and in your files in the same way.
Clean up the code by keeping controllers to a minimum.
On the model in CodeIgniter, there is a test tool that is quite enough for testing them.

Answer 6

Colleagues, I join everything that has been said above.
I will add from myself.
unit tests on old code is a waste of time, because there is probably redneck code, it will be extremely laborious to cover it with high-quality tests. I would do so.
1. write unit tests for all new functionality. give programmers to educate makkonel and something on the practices of TDD, SOLID, GOF.
2. cover old and new functionality with integration tests.
If there are any background interactions, uploads, etc., this can be checked.
The user interface can also be tested automatically.
see BDD. Let the browser automatically run all the functionality of the site.
3. I used hudson as a CI server. I was quite satisfied with everything.
the same Jenkins is its fork
4. only one person should be responsible for production.
you can organize it like this. we make a separate branch, or a branch, or even a separate rap.
it's how you organize.
Only one person can commit to it. This person reviews all code before pushing it to the production repository.
accordingly, this person “drinks the brains” of programmers so that everything is so. Well, if something happens, there is a person responsible for this matter, from whom it is asked in the first place.
5. at the expense of the www-script - this is too much, if there were 30 programmers and the functionality would be rolled out every day (or at least once a week by different people), then yes, otherwise I think it is superfluous.
there are situations when you have to do debugging on the live commits and www-script. One of the programmers will definitely do this ...

Answer 7

I organized it like this:
- sources in a turnip under Mercurial
- a clone of a turnip on a test server, dokrut points to the desired directory
- capistrano makes a production deployment
- if you have to edit the code in "extreme" conditions, then there is a separate user on the server, too, with his clone of the turnip and installed capistrano, that is, even urgent editing via ssh consists in pulling fresh changes from the main turnip, making urgent changes, commit to the clone, push to the main one, cap deploy

Answer 8

We have this:
Tracker - redmine, control system version of SVN.
Development is carried out on 3 development servers on which two teams work. Two main ones, one in case there are parallel tasks. All changes are stored in SVN. Testers pre-test the instance directly on the development servers. After successful pre-testing, Hudson builds an instance on a test server.
After successful testing, the package built from SVN is installed for pre-production partly manually, partly using sh-scripts. After another shortened testing cycle, it is similarly installed on production.
Unfortunately, unit testing was not implemented, there is not enough time.

Answer 9

About the wiki.
Create a docs folder in the repository and throw text files with a description there. github is able to show certain formatting nicely.
But there is a better option, try GoogleDoc.
You can even make a corporate one with your own domain.
plus compared to wiki
1. simultaneous editing by several users
2. cool history of changes
3. cool editors, different formats for office data
4. data export to different formats
is shorter, I really like this option) I use it myself)

Answer 10

you can also add the convenience of working with different configs for production and development. so that it is not necessary to edit the configs after the checkout from githab
Read more: ikuznetsov.blogspot.com/2012/02/blog-post.html