I am developing a web application for my coworkers, and from a little management app it is becoming a more and intense large project that is involving more people as I go. I am pretty sure my boss will ask me to add even more as I will go on.So I became unsure if I am doing things right, because I never worked on large projects (actually this is my first job).The webapp I am working on is used by my company so I cannot do edits and changes while they are working on it; I will obviously expose them to some bugs and ux issues that could be deadly, like adding wrong data in databases etc. etc. etc.So in the last months I divided my web application in two directories; one is the main index.php where they work, the other is the development directory, in the same server, which is only used by me.When I finish all the edits and changes, I move everything in the development directory to the main directory used by my coworkers.But I ask myself: is this a proper way to develop and test web apps? Lately I had been caught in terms like continuous test driven development, unit-testing, sandbox development, etc. and moreover, making little changes in my code and uploading it every time to see what happens doesn't sound very professional to me anymore.So how can I understand if this is a proper way to develop web applications? I am not sure even if I need all this testing, since I am the only webdev here.I know that this can be too broad but I don't know any other ways to ask something like that as I know just a few things about web development in a larger scale. This is something that could be answered by a software architect for example, or a senior web dev, but I am the only web dev here.
What is the proper infrastructure and release cycle for developing and testing an application?
web development;testing;web applications;development process
In a good environment, you'd have three separate arenas. Each with their own database, so you can work without fear of destroying production data. Local DevNothing leaves your local work station. TestThis is where you upload your changes when you think they're ready to be tested by a business user. You do have a business user test your changes before they go into production, right? (Btw, this is called UAT [User Acceptance Testing]). Production The more separated these environments are, the better off you'll be. Having separate environments makes it impossible to unintentionally break prod while you're developing. The Test/Dev environments are sandboxed away where any changes you make cannot harm production data. Preferably, Test does not live on the same server as Prod. (I've even seen some put it in an entirely different NT Domain, but that's overkill IMO.) Having separate Dev/test environments is nice because it gives you an opportunity to practice your deployment strategy. That said, you can absolutely get away with only having 2, a Dev/Test and Prod. It's not ideal, but I've made it work in the past. TL; DR: 3 environments that can't speak to each other. Dev, Test, Prod. As for automated tests, I would highly encourage you to watch a few tutorials and practice a bit. I'm admittedly a TDD zealot, but studies have shown that it reduces the number of bugs that make it into production, where fixing them is orders of magnitudes more expensive, while only costing between 15-30% in cycle time (time to delivery). It's well worth the investment in my humble opinion. One personal note...Don't stay at this job long. Buff up your resume and go find a company that will invest in you as a developer. The longer you work without the mentorship of a veteran developer, the more bad habits you'll form. Working with experienced people will help you avoid many of the mistakes you're going to make learning all on your own. 