débutant à la gestion de projet php 'correcte'

Question

J'ai créé beaucoup de projets PHP dans le passé en me basant sur la méthodologie de développement rapide 'changez-le, téléchargez-le'.

Je commence un long projet (estimation de 6 à 8 mois) pour fournir une application web hébergée assez complète. Au cours des dernières semaines, j'ai cherché la meilleure façon de gérer ce projet (mon code actuel est très bien). L'application aura une version initiale, fournissant des fonctionnalités de base et une version supplémentaire offrant des fonctionnalités avancées. Je n'ai jamais utilisé SVN, Trac, le suivi des bogues, les serveurs de mise en scène ou les outils de déploiement, donc c'est tout nouveau pour moi. D'après ce que j'ai appris au cours de la semaine dernière, voici ce que je cherche à avoir.

4 x VPS avec 128 Mo de RAM (256 burstable) et 10 Go d'espace disque dur.

Configuré dans la configuration suivante

1. de tools.ops.ourdomain.co.uk - serveur SVN hébergement, Trac, et le stockage sécurisé de fichiers pour le téléchargement et le DNS (où les serveurs de noms pour le point)
2. development.ops.ourdomain.co.uk - environnement de développement pour travailler sur la version de tronc du logiciel. Dossier htdocs mis à jour automatiquement sur la validation SVN
3. staging.ops.ourdomain.co.uk - où les 'versions potentielles' sont déployées pour les tests.
4. production.ops.ourdomain.co.uk - serveur de production sur lequel les «versions finales» sont déployées.

Est-ce que cela a du sens? Dois-je déposer mon serveur de développement sur ma machine locale? Est-ce logique de mettre le DNS sur le serveur d'outils ou non? Deuxièmement, quelle est la meilleure méthodologie de développement pour un seul développeur? J'allais d'abord planifier toutes les fonctionnalités, par exemple "Authentifier un utilisateur", "Déconnecter un utilisateur", puis les créer en tant que tickets de trac. Le «comment» et le «où» pourraient ensuite être mis au point lorsque j'arriverai à la tâche en question. Serait-il plus logique de planifier toutes les méthodes de classe (et les fichiers généraux) et ensuite de créer des tickets pour celles-ci?

Merci d'avance.

Answer 1

Voici quelques conseils basés sur des méthodes agiles, ce qui devrait être très bon pour les équipes d'un seul homme, car elles n'ont pas beaucoup de frais par rapport à l'utilité.

• Faire un script de déploiement - une seule commande, vous pouvez exécuter pour déployer l'application. De cette façon, vous pouvez facilement répéter les étapes que vous suivez pour déployer l'application. Cela réduit les chances de faire une petite erreur ou d'oublier une étape lors du déploiement en production ou en mise en scène.
• J'ai trouvé que le développement sur mon propre PC est généralement le plus rapide pour moi. Pas de retards de réseau lorsque vous travaillez, familiarité avec le système d'exploitation et les outils. En fin de compte, ce qui compte, c'est la préférence personnelle.
• Ce serait une bonne idée de avoir un environnement de mise en scène, de préférence sur le même matériel/logiciel que l'environnement de production final. Cela vous permettra de confirmer que tout fonctionne bien là-bas, et peut permettre aux clients de tester les changements.
• Essayez de faire publications périodiques, similaire à Scrum sprints. Choisissez les fonctionnalités que vous souhaitez compléter pour la prochaine version. Cela vous permet de vous concentrer plus facilement sur les fonctionnalités les plus importantes lorsque vous savez ce que vous devez faire, et facilite également l'affichage des progrès (OK cette version comporte A, B et C). Ne choisissez de nouvelles fonctionnalités pour la version actuelle que si vous avez terminé celles que vous avez choisies. Marquer chaque version dans le contrôle de source.
• Pour ce qui précède, vous pouvez utiliser Trac pour garder une trace des fonctionnalités, comme vous l'avez dit. Quel outil ou approche vous utilisez n'a pas d'importance, tant que vous avez une sorte de carte ou de document sur ce que vous faites.
• Si vous êtes familier avec les tests unitaires, vous pouvez envisager d'utiliser Développement piloté par test. Dans le cas contraire, il pourrait être une bonne idée de commencer à apprendre sur l'unité des tests

Et last but not least, faire un calendrier et de s'y tenir. Sinon, votre projet peut prendre beaucoup plus de temps que prévu.

J'espère que certains d'entre eux vous aideront à éviter certaines erreurs que j'ai faites plus tôt dans ma carrière =)

Answer 2

Si vous pouvez le changer sans trop de frais, doublez ou quadrupliez la RAM. J'ai un VPS "workbench" de 256 Mo (fixe) et j'ai eu du mal à faire fonctionner Trac/Python, Apache2, une ou deux applications PHP, et une connexion de bureau à distance en même temps (la boîte refusait de faire quoi que ce soit Mémoire insuffisante"). C'était un Windows Server 2003 VPS, Linux est probablement un peu plus économe dans l'ensemble mais plus de RAM ne fera pas de mal. En ce qui concerne la planification, je ne sais pas si les billets Trac sont la voie à suivre pour les premiers pas et le développement de base. Ils sont parfaits pour gérer des problèmes, des idées et des fonctionnalités uniques, mais pour une vue d'ensemble (exigences fonctionnelles, ébauches sur ce qui va être résolu, listes de fonctions), vous pouvez être mieux avec un document Office, des diagrammes UML ou tout ce que vous utilisez pour collecter des idées et construire une structure avec.