This is related to http://drupal.org/node/202191. Once we figure out what we are doing in that ticket, we need to set up a dev env and write our "best practices" for how we will work within it. We'll also need to determine who has access to what in that process. I'm just creating this issue now so I don't forget that we need to do it. :p

We do have a dev subdomain on the dd.com server right now but we really need a planned workflow so new devs coming in to work can be handed a doc that explains what we are doing and how they can get up to speed without stepping on toes.

Comments

gusaus’s picture

gusaus commented

The larger issue (I think) would be if/how we'd allow/accommodate 'multiple' dev environments or sandboxes (dojo's)? Essentially one of the thoughts we had for Dojo.org:
http://groups.drupal.org/node/2989

Matt and crew have made some good progress w/ what used to be the DojoDuju (that we used for a moment in time):
http://drupal.org/project/druplet

I 'think' this project (provided by the same good folks that are hosting the dojo) could provide a similar set of functionality:
http://drupal.org/project/autopilot

The ability to provide a dojo (self contained pms/casetracker; dev environment; collaborative workspace) for any 'qualified' group/subgroup would open the doors for a huge amount of drupal goodness.

add1sun’s picture

add1sun commented

Hrm, well what we're talking about at this point is the one codebase and development workflow for the dd.com website itself. I think the idea of additional sandbox sites should be introduced and discussed in a new issue as a feature request.

gusaus’s picture

gusaus commented

Wasn't quite sure how far I'm reaching here... so the dev. environment/collaborative workspace for the dojo site couldn't be proof of concept for something like this? Thought a system like this might work, say, if we broke the major development chunks down into sub-groups?
http://groups.drupal.org/node/7999

add1sun’s picture

add1sun commented

Hm, no I really don't see these as related. How we set up the dev env for the dd.com website doesn't have anything to do with "working groups." Everyone working on the dd.com site needs to work on one codebase using the same repo and dev/QA/live workflow.

As I mentioned, the idea of providing an entire dev env for other potential projects is out of scope for this thread and is something best addressed in another thread since that is introducing an infrastructure feature, not a basic task to the core Dojo needs.

gusaus’s picture

gusaus commented

ok - moved the 'multiple' dev environments or sandboxes' stuff here - http://drupal.org/node/208344

add1sun’s picture

add1sun commented

Ok, we have SVN, viewvc and Project set up on the dd.com server. We now need to move the Unfuddle svn stuff over and create a stable branch for the existing site. Trunk will be used for new development. We need to document the following:

1) What we have set up
2) How to use/develop within it (where does stuff go, how do we QA, best practices kind of stuff)
3) What are the criteria we want for allowing people access?

brenda003’s picture

brenda003
she/her
commented

Couple initial thoughts.. what /is/ the desired workflow? I've seen it done a few different ways. Local -> staging/QA -> production, or development -> QA -> production. Files can be pushed live easily, but any database changes usually need to be redone manually or exported/imported properly. You can export views and whatnot, but if there's users and activity there's no easy way (that I know of) to push other changes live.

Criteria to allow people access: just some way to know a person isn't going to break things. ;)

Perhaps we could have something like anyone w/ access can claim a task in the issue queue, but if isn't done after X amount of time someone else can assign it to themselves.

I can *try* to write up an actual more thorough document later. But if you know more about it, jump right in!

add1sun’s picture

add1sun commented

I am thinking that we can keep things pretty simple. So something like this...

Work on local checkouts
Dev/QA site is set on cron to svn up from trunk every 5 minutes
Live is an svn checkout of a stable branch
When we are ready to move to live, we branch svn and update the live server to the new branch

As for DB changes once we have a live/moving target site we have a few ways to handle them.
- Put changes into code (database changes in update hooks in our custom .install file) We did the entire upgrade of Sony Musicbox this way. Every time we made a change we added it to the install file with each change in its own update hook.
- Create macros
- Maintain a change notes checklist file in svn with any minor settings that we don't automate and need to be done manually
- All views need to be added to code through a views.inc file in our custom site module. You change a view manually, you need to just copy the new export into the file and you're done.

It would probably work well for us on the initial dev cycle to do a weekly DB snapshot that folks can just work from directly. All devs just need to make sure that their DB changes get onto the dev/QA site - either manually, macro or in code, whatever works for what they need - and then we all know that grabbing the last weekly dev DB snap will have you up and running. We can manually add the small amount of new content that happens on the live site in the meantime and when we make the big switch, just use the dev/QA database as the new live DB.

So I dunno if that is all clear as mud but I'm definitely all ears to suggestions from others.

senpai’s picture

senpai commented

I like the idea of putting db changes into the install file update hooks, cause it gives us a way to track what's happening over the course of time without having to resort to me creating multiple db snaps during a development weekend. If others are making sweeping changes at the same time I am, this is the only way to ensure that everythng stays in sync.

After all, if you've got to write an update hook for it, you'll have to ask yourself, "It this really worth changing"? ;-)

+1 for updates via install file.

I'm also for the idea of working on a localhost until your code is stable and works IN ALL SITUATIONS before pushing it to the dev server. This way, nobody breaks our test environment unless we're all staring at it while someone is trying something that we've all agreed might break the site. There's nothing that slows down progress on a Saturday morning quite like realizing that someone else has 'accidentally' whitescreened the dev server just as you're taking your second gulp of fresh, hot coffee...

So I'm +1 for Addi's proposed workflow. Localhost code creation and personal QA, then push to dev/stage for viewing by all. Dev/stage gets pushed to live only when our Issue Queue (yay for Project.mod over Trak!) says we have no critical bugs for 5 whole days. And we branch. A lot. 1.0.1, if we have to, but we need to be able to go back in time to yesterday, the day before, or the day someone hacked a contrib module to prove their point and it accidentally got committed to head last month but no one noticed.

senpai’s picture

senpai commented

FYI, the Unfuddle account should have a fully patched version of D5.6 in it. I'm not sure if the db is good on the dev server though. I never got a chance to see it in action cause we didn't have the URL working correctly or something like that. When the time comes to add the site to the new SVN, somebody throw a board at me. I'll toss my latest db snap into the mix. I just don't wanna add it to SVN, for obvious reasons.

add1sun’s picture

add1sun commented
Status: Active » Closed (fixed)

Project is abandoned. Closing all issues.

gusaus’s picture

gusaus commented
Component: Miscellaneous » Infrastructure
Assigned: Unassigned » gusaus
Priority: Normal » Critical
Status: Closed (fixed) » Postponed (maintainer needs more info)

We need to reevaluate not only how/where the dev environment is set up, but also the live site. I believe the dojo site has switched hosts since January. There also is a slight issue with drupaldojo.com not pointing to the right place.

gusaus’s picture

gusaus commented

BlakeLucchesi (http://groups.drupal.org/user/3107) has begun putting up the new dojo site on a development environment. We will use an unfuddle account (thanks Chris Bryant- http://drupal.org/user/70716) to host a SVN repository with all of the custom code for custom modules and themes.

Code and Subversion
Domain: http://lesscoffee.com (An extra domain of Blake's that we can use during development, though if we can get a dev.drupaldojo.com pointed to his slicehost IP address he can setup apache to accept that as well)

Subversion hosting is provided by Gravitek Labs via Unfuddle. It is setup so that when commits are made to the unfuddle account it will automatically deploy the code to the development environment.

Source code is being handled via drush and cvs_deploy, all modules are checked out via ssh command line using the drush module so that updates are handled automatically. Blake will install any modules we need.

Subversion Layout

/head/custom/modules/... custom modules ...
/head/custom/themes/... custom and contrib themes ..
/tags

Server Environment
The server is running Ubuntu Hardy with PHP5, MySQL5, Apache2 pre-fork. We will likely want to run the production server with memcached as well.

Again, source code is being handled via drush and cvs_deploy, all modules are checked out via ssh command line using the drush module so that updates are handled automatically.

gusaus’s picture

gusaus commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Dev is set up - http://dev.drupaldojo.com/