Need to setup a practical dev environment
-
Hi all,
We used to have a local development server for our dev team with cPanel installed to manage the accounts and the dev team were given full servers access as mapped drive via SMB. So they could all open files directly from the server, work on it and save it back. This used to be the common practice and once the development is completed, the code is committed to svn repo and then moved to our staging server for the Account Managers and the client to test before its pushed to live.
Now the server is replaced with a new one and I would like to avoid giving direct access to dev team to prevent problems like keeping old files backup without proper naming convention (backup_old, oldbackup_files etc) and also avoid disk being full most time due to lack of proper housekeeping, trace out an issue in the middle of the night, because no one know who did what on the server that caused an issue.
What I proposed to the team was to setup development environment on all dev team's machine using tools like Bitnami/vagrant and then create the port in dev server by the admin, dev team creates the files on their machine, commit the codes to repo and then checkout the codes to the dev server, which will enable us to keep a good track of all changes and gives dev team the flexibility of working from anywhere as the starting point of the codes are on their machines.
They have the following arguments:
- Will this local development environment works perfectly on WAMP as the server used is LAMP?
and they know it works perfectly on MACs but may not be on Windows/get everyone MAC!
This is practically not an immediate solution as the cost for MAC would be double that of windows machines.
-
How to collaborate when multiple users have to work on different files of the same project. Like css team working on css files, html on their files etc. (My suggestion was to let them checkout the code to their local test environment and work, commit on each changes back to repo)
-
How can they make changes on db when it is on each of their local machine. (My suggestion- use the servers accounts/project account db, on the config file, give the IP of the server and username/password instead of localhost and local username and password)
What I would like to know from you all is:
-
Is this the right approach on a multi user rapid development environment? (We have 50 developers now working on drupal, wordpress, sharepoint and in house cms)
-
What could be my possible good arguments to make sure that the whole process benefits overall company and the team without risking the direct access for all users?
- Will this local development environment works perfectly on WAMP as the server used is LAMP?
-
Start with making everyone use a repo for everything. Look at GIT and Mercurial. GIT is the big player now. Subversion (SVN) was great but GIT is more powerful. You can use a hosted service like GitHub or BitBucket (that's what we use) to handle this for you or look into Alstassian's Stash server product that you can host yourself on Linux.
-
Funny part is we do have Gitlab setup by me almost 2 months back, but couldn't get all on board to start using it yet!
No one is really willing to adapt or learn this thing due to the learning curve. I am still working with some other team members to do a training, testing and implementation plan. Its just that people don't want to change from what they are used to. Its very true that its not an easy task to switch and I agree but there should be a point where we should upgrade our skills and be up to date with new market requirements.
Another issue is if we completely switch to git, its gonna be a tough process of switching every single projects we did, (we do hosting for the clients as well) from svn to git, which might take a long time to complete.
What I am thinking is to start new projects with Git and slow reduce usage of svn and then kill that eventually.
How are development companies handles this? Shared db/collaboration on coding etc?
-
Yes, new code on Git and keeping old code on SVN. That makes good sense.
-
So some new things happening on this one.
The dev team heads took the initiative and working on the GIT implementation first started with their own testing and soon will be a training session to introduce this to the team.
So the new plan is to use vagrant for deploying dev environment on each dev teams machine, use GIT for revision control, but the question now is how to get a team to work on DB based sites like CMS. How can we get team members to collaborate when there is content involved, I am still looking at options for having revision control for mysql, anyone done this before?
-
Anyone used/knows about collaboration on DB? We are still stuck on how to manage DB once we start using GIT
-
The only revision control for databases I have used was from RedGate but that is designed for MS SQL Server.
-
@JaredBusch I wish they had something for MySQL, Just wondering how are the guys who work on CMS sites like Drupal work as a team! I'm sure at least a small percetage must be using git, but how on the DB
-
I've read about https://www.drupal.org/project/backup_migrate but again, there must be something like a version control like GIT that can be used.
-
So what languages are even in use? There's no sense in even discussing what OS/platform to use if the language(s) haven't been decided on. Your available choices are going to be vastly different if it's C#/MS SQL Server and PHP/MySQL, etc.
A proper IDE, like PhpStorm is cross platform anyway, so it doesn't matter if they use Windows or Mac (MAC = Media Access Control, or it's also a make up store).
Don't jump the gun and work backward. It is important to keep in mind that the development environment should be similar to production, otherwise tons of extra staging tests have to take place if you're working on Windows but hosting on Linux. Case sensitive file system with OS X is close enough to Linux/BSD to where it'd be fairly fine, but again we're back to available languages, libraries, etc.
I second git though, we use that, it's pretty great.
-
Development is for PHP MySQL.
For making a streamlined local dev environment, we will be mostly going to use vagrant
File revision control- Git
Then comes the DB part which I am still checking.
-
OK:
Machine can be anything, if it's Windows then you need to take care to worry about file case sensitivity. I'd certainly keep all table and column names all lower-case in MySQL, not doing it is a seriously idiotic mistake. I imagine you'll be hosting on something like Linux or BSD, and if not you should otherwise you'll be wasting money for no reason.
The IDE has to be PhpStorm, not Eclipse, not Netbeans, not some other highlighter garbage like Notepad++ or Sublime, it has to be PhpStorm, it is the best there is out there and speeds up development a whole hell of a lot when used to its full potential, plus it fully integrates with git (and cvs, svn, etc), TDD, etc.
Use git.
Always use utf8 (utf8mb4_unicode_* in MySQL itself), do it right the first time.
And of course I've got a billion other tips for proper PHP programming.
-
@tonyshowoff Thanks a lot for the tips. Basic programming standards are already been followed. I am just moving our team out of traditional subversion and using a central server for development to GIT and give devs the freedom of developing on their own machines (using vagrant we will be deploying linux boxes to setup the environment). Dev team also use tips from http://www.phptherightway.com/
And since we decided to go with GIT, we already finalised to purchase PhpStorm, after extensive evaluation on netbeans and other products.
-
Seems like someone has also tried incorporating mysql on GIT.
http://ben.kulbertis.org/2011/10/synchronizing-a-mysql-database-with-git-and-git-hooks/
and there is
https://klonio.com/ but still under development -
@Ambarishrh said:
Dev team also use tips from http://www.phptherightway.com/
echo "Hello, $name\n";
If they're doing this, god help you.
Skimming through it isn't too bad though, but using double quotes when not escaping character is just an open door to a pack of feral dogs ready to tip over your table, knock your delicious PHP all over the floor and rip it to pieces.
Some things to consider:
http://community.spiceworks.com/topic/post/2672172
http://community.spiceworks.com/topic/post/1954828
http://community.spiceworks.com/topic/post/1272514
http://tonyshowoff.com/ (My blog, not a lot here yet, but some, primarily focused on PHP and MySQL)
Some other criticisms:
- Composer is a great package manager that will make your libraries super bloated as hell and let you write an absolutely massive autoloader class, it's wonderful crap.
- Twig is actually a neat templating library, but PHP is already a templating language so you're just adding overhead for no reason. Why add thousands of lines of code, tons of CPU process and memory usage to turn {% this %} into <?=$this ?>?
- I do like how it talks about xdebug (which can integrate with PhpStorm), but it seems to talk a little too much about forcing suppression with @, which is bad practice.
- It should go more into using E_NOTICE and E_STRICT, if these are not enabled in development (and logged in production) the developers are going to spend way more time debugging and write much crappier code, thought it does mention using them, but very briefly and without detail.
- I have to bring up the fact they seem to use double quotes, though not always, and also seem to think $variables in the middle of strings is fine.
Overall though, it's pretty good compared to most tutorials/manuals out there, especially W3C and that other one people link to all the time, especially in regard to proper utf8 support.
PhpStorm will also help with a lot mentioned in there such as PHPDoc and so on.
-
My role mostly to setup the infrastructure for the team but not in programming, but I am sure these tips can really help our dev team, and I am sharing it with them now, and your blog too, seems like they could benefit from your posts as well. I am concentrating more on how to give them a collaborative environment not just for files but for DB as well. Thanks a lot for all that feedback.
-
Well yell at them until they do as I say! Or at least pass it on maybe
Edit: I see you did, thanks
-
Yeah,they are on a remote office, but got the main guys here with us for few days, so thought this is the best time to brainstorm and finalise on how we could proceed. so all of this is coming at the right time!
-
Have you thought about building the application(s) using Docker containers to standardize the dev/production environments and make everything platform independant?
-
Docker/Chef is still in the plans but require more planning and testing before we go with this