Need to setup a practical dev environment
-
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
-
@Ambarishrh take a look at Ansible as well, it may be easier to use if the prior experience with Chef isn't there. I'm just now starting to educate myself on Docker (and containerization in general). Although there is a learning curve, it looks like the time spent on education would be returned tenfold when reliably put into practice.
