That is, if we need a professional team consisting of analysts and programmers, typesetters, designers, etc... All coordinated by one or more project managers and we also wish to have a control on the quality of the resulting product as its evolution over time to meet the future needs of our business processes, we need to use any of the existing methodologies for software development, which supported on a hardware structure that goes somewhat beyond the typical "free hosting".
Software and Tools
Nowadays, the tendency to create or maintain large projects is based on the Rapid Application Development. This is a software development methodology, which involves iterative development and prototyping work on the following basic principles:
The key objective for rapid development and delivery of a high quality product is to reach a system of relatively low investment costs.
In which we try to reduce project risks splitting it into smaller segments and thus making it more easily by making changes during the development process.
And in which we orient ourselves to produce high quality systems quickly, primarily through the use of iteration by prototypes (at any stage of development), promoting the participation of users and the use of computerized development tools. These tools may include builders of Graphical User Interface (GUI), Old Tools such as Computer Aided Software Engineering (CASE), or database management systems (DBMS) as well as programming languages of the fourth generation, code generators and object-oriented techniques.
We will put special emphasis in meeting the business need, while technological or engineering excellence will have less importance and is dependent on the first. Yes, we all know that we would like to do it the other way, but do we not owe it to our customers?
Also the control of the project involves the development of priorities and defining delivery deadlines. If the project began to be deferred, we will emphasize on the reduction of requirements for the setting, not in increasing the deadline.
Generally we will use techniques of Joint Application Development (JAD), where users are intensely involved in system design, either through consensus structured workshops, or electronically.
Remember that the active participation of the users is essential.
And of course generate the necessary documentation to facilitate the future development and maintenance.
Some of the projects in which I have participated based on Joomla have adequate methods which have been adapted to the needs of the development of both the Framework and our CMS portal or extension, enormously facilitating the success thereof.
Structure Hardware and Servers
One of the first steps to start developing is to have an infrastructure and server hardware well defined to facilitate the following:
- Version control
- Operational prototyping
- Automated deployments
- Automated unit testing
- Automated testing functions
- Continuous Integration
For this we will configure it for our clients an environment as shown in the following graph:
Let us see each of the parts with more details.
The heart of all this is a web server called Nginx. Why this and not an Apache server? The answer is simple because with Nginx we can configure a high-availability system, with load balancing, separating the dynamic content from the servers which deliver only static content. So, in addition the system is ready for a steady migration to the cloud. If we need Apache compatibility, we would mount it below the Nginx or in parallel for those tasks where compatibility is essential.
What is also part of the heart is the MySQL server. Or more specifically the farm of servers that synchronized between them, when necessary, serves a different environment that displays the customer portal.
A PHP interpreter is responsible for the implementation of the pages which Nginx should serve. With the necessary modules for Joomla to deploy all the power required by the customer, but removing all of those which do not contribute with any added value, which means an increase of charge in the system or the slightest risk in terms of security concerns.
Completing finally this "core", the NFS server responsible for the exchange of files between the rests of the applications that make up the graph above. The communication of the "core" with dedicated high-speed lines, facilitate the composition of the page requested by the Internet in the shortest time possible.
The Developer Zone:
Each developer has an IDE environment where you can find the tools integrated of the version control management, and various utilities that facilitate the development of extensions for Joomla.
All which is centralized in a GIT server that connects to the kernel NFS server to dump the versions validated by each team member.
Continuous Integration Area:
Configuring a deployment tool and a Continuous Integration Manager responsible for the launches of unit testing (PHPUnit and JUnit) and functional (Selenium) as well as scheduled deployments between different environments.
In this way we simplify the unit testing phase of development teams in a first integration between different developers and future user tests by automating those functional tests which are mandatory every single time you change a Joomla project.
Finally, Environments Area:
We have four distinct environments which are isolated from each other. Being Joomla a content management system, there is a particular situation of feedback from the production environment to others. It is necessary for the reproduction of certain circumstances that periodically back up with false data to the Preproduction environment. This facilitates the reproduction of unwanted situations that may occur by content managers on the operating system.
An essential environment such as I+D+I enables the enormous possibility prior to the assessment of extensions and functional solutions. Having identified these procedures to repeat them in the integrated development environment by integrating it in the team's regular cycle in that moment. This environment often has a high contamination level for residues resulting from the constant tests, so that restoration procedures are the same from the development environment, refreshing only those changes done after integration testing is in beta (preproduction environment).
But let's focus on an environment which receives more stress from our team: The development. An environment which is constantly changing, where we integrate the changes after the unit tests. An environment from which developers receive information of "debug" exactly the same as they do in their private test environment but with the interaction of changes with the rest of which were made from the rest of the team.
One last environment, the Preproduction (or beta) facilitates that the user will be able to test exactly like you would on the production system but without the risk of stopping it.
All these environments are configured to use different databases (falsifying information if required to comply with the legislation of the country of the customer (i.e. in Spain LOPD and LSSI), different mail servers (real or simulated) to avoid sending emails to real users during testing but would allow to measure the load which these shipments generate, independent backup systems, etc…
Only in this way we can tackle a long-term project and/or low latency Joomla with the same quality and safety that if you perform the test with proprietary products in which they demanded the same kind of architecture.
Let’s not be less demanding with ourselves because of working with open licenses.
Original article in Castellano: http://magazine.joomla.org/es/ediciones-anteriores/julio-2013/item/1391-como-abordar-grandes-proyectos-con-joomla