Good practice for managing web development

Question

I understand that the phrase “good practices” is a bit dubious and excessive, but I think this relates to my question.

I have good web development experience, but I would like to hear some good basic practices when doing freelance work regarding project management.

For example, I have the target domain mydomain.com. Do I have to run all my tests in a subdomain, i.e. dev.mydomain.com, protected by .htaccess, or in some other ways?

I am familiar with SVN, but not for web development. What is the best way to control website versions?

I installed two databases, mydb _ dev and mydb _ rel. Does it make sense to do all my work on _dev and then pass the structure to _rel? What happens after the first release?

If you can answer some of these questions or link me to a good resource, that would be great. My searches still give HTML lessons!

Answer 1

What I usually suggest is the following. The team should have 3 types of "deployment" environments:

• development environment: here developers work and can publish
• test environment: tests are performed here, also showing, possibly, to the client. Only work products should be deployed here.
• production environment: final deployment of a working and used product

Here is something that relates to this concept. I would suggest that the "test environment" (or pre-release environment) is on the same server with the same configuration as the final "production environment".

As for version control, I would use it only for the version of the source code. You can use any version control (or even configuration tool) that you like. This is good practice for branching, so whenever you release a product (deploy it in a production environment), you create a branch with the appropriate version number. In parallel, you continue to develop on the main branch. This has the advantage that you can make a possible fix that can happen to your version, and you can redeploy the branched copy without redeploying the new features that were added to the main development branch at that time. Searching the Internet for best branching practices, there are many things around. However, I would not use SVN or something to properly manage your site. At least I have never heard of such a practice. It would be best to back up your production environment daily on a server somehow ...

Answer 2

What are we doing.

• Use a framework that allows testing outside a deployed web server. We design and test on laptops. Some people use Glassfish running under Eclipse for testing. Another use of Django that works autonomously. We have databases on our laptops for development and testing. We use configuration files to make sure we use "development" names for databases, directories, etc.

• Perform integration testing in a virtual machine. Our hosting is Red Hat Enterprise Linux, so we have Fedora VM, which we use for testing with Apache and MySQL (or Oracle) and all this technology stack. We have test integration bases in the VM environment. We use configuration files to make sure we use "test" names for databases, directories, etc.

• We use products that have a very neat deployment. Glassfish / Java applications are deployed with WAR or EAR files. Django applications use the Python installer setup.py . Thus, we can install in production, mess with the database, and we work. We use configuration files to make sure that we use "production" names for databases, directories, etc.

The first release includes the creation of a database for the first time. We provide a script (or in the case of Django, we run the manage.py syncdb ) to create the database.

When making circuit changes, we either have scripts or instructions. We have to do it in the test and again in production.

When deployed into the visible to world production, we do this.

• We have a virtual machine in our hosting environment that "organizes". We get it to work. This is not visible on the Internet. We test our components, install them, start changing the script database schema (or follow the manual steps if it's complicated). We usually work on a copy of the production database.

• Then we clone this virtual machine to create a production virtual machine. We are changing the production configuration to use an updated copy of the production database.

We do not have a database named "prod" that is difficult to work with. We have "prod_3" in production, "prod_4" when setting, when we do the update. Then we change the configuration file to use "prod_4". prod_3 may freeze until we need disk space to create prod_5.

Answer 3

A few tips that I found useful in my work:

• I maintain a personal wiki page for each project that contains all project related data. Since this is only for my personal consumption, I can arrange each of them as necessary.

• Keep a log of questions (on the wiki page or elsewhere) that appear throughout the project. Instead of bombarding your client with random messages or accidentally forgetting to ask a question in a timely manner, keeping a journal will allow you to send one consistent and compiled letter every few days with questions related to the project.

• All developments are local (MAMP, XAMPP, etc.). Thus, your client never accesses the website when you use it, therefore, bypassing unnecessary confusion (why am I becoming blank screens now?) They worked 5 minutes ago !!).

• Click from on-premises development to the staging server through Capistrano . This can be done again for production. It’s much easier to track any build scripts (for example, JS) and much more efficient than FTP

• Use SVN to manage all resources - content, templates, comps, your work site, exporting databases, etc. A well-organized repo will not get out of hand if you set it up from the very beginning. It never hurts to have an extra backup, even if you know you will never touch the file again.

Answer 4

As for version control, I would say that everything is under control, which is not created dynamically. For example, if you application generates a lot of .txt files on the fly, you do not need to set them, but everything that was created only once should be versioned.

Regarding the choice of version control system, I would recommend something other than SVN (maybe Git or Mercurial), but this is a more personal preference than any significant reason.