I thought about this, and this can be done. But it is also nice to be
able to help another developer quickly, by actually viewing the site in
a browser, especially when they are having an issue with frontend code.
Currently, I manage a developer remotely, and he does do a php work, but
does a lot of css work at the moment. Since he is still learning there
are times where I need to see what the issue is, and the easiest thing
to do is just look at the site firebug.
Could have them have their own branch, have them commit the bug, the
deploy the branch on my own local environment, but once again seems like
a lot of trouble just see that a div has too much padding on it :)
On 8/11/2010 9:23 AM, Саша Стаменковић wrote:
If every developer have its own branch, he can commit to his branch,
so you can diff with trunk, and see cnahges.
Regards,
Saša Stamenković
On Wed, Aug 11, 2010 at 3:20 PM, Paul <[email protected]
<mailto:[email protected]>> wrote:
One more thing I thought of, was accessing a developers local
environment.
Currently, since we have everything on a shared dev server, I can
easily look at the the teams code (great for the junior
developers), and I can access their local copy of the site on a
domain (site.paul.dev).
Wondering if you do anything similar with your teams. Having
each developer with their own local setup, definitely complicates
this a bit.
On 8/10/2010 3:44 AM, keith Pope wrote:
On 10 August 2010 01:09, Paul<[email protected]
<mailto:[email protected]>> wrote:
Thanks Keith this is great! So for local dev, you let the
developer choose
their own environment. Or do most of your developers have
the same setup
(ie. all developer have a mac)?
Thats right, we allow any environment and allow the staging
server to
detect the environment specific errors. Developers use Mac,
Win and
Linux plus most have VM's for testing.
I believe the most important part of a teams setup is
automation, this
solves so many problems!
On 8/8/2010 4:36 PM, keith Pope wrote:
Hi,
We use the following setup:
Local dev setup (Development)
Developers can use any IDE/Editor they like and can
have their own
LAMP etc setup.
Ant - Used locally to configure, build and test the
application
(checks for dependencies etc)
Data - Mysql weekly dump, sensitive data scrambled.
DBDeploy - Used to version the database so everyone
has up to date
schema's
Services (Solr etc) - Shared machine, available as VM
Everything in SVN currently
Dev build server (Staging/Testing)
Custom application for quickly setting up versions of
the software on
the same server config as the live environment. This
lets the
developers checkout and setup vhosts for user
testing/demos,
integrates with the ant build system.
PhpUnderControl (QA)
Does all the continuous integration stuff we need...
I would say our project is fairly large and I aim to
allow the
developers to setup a fresh install within a couple of
minutes (minus
copying the database)
Currently to configure our application fully you need
to do:
ant refresh-properties
ant
ant apply-db-changes (if there are deltas waiting)
Takes a couple of minutes, the main thing here is to
automate as much
as possible, this makes dev, testing, integration and
deployment much
easier!
On 8 August 2010 11:32, Wil Moore
III<[email protected]
<mailto:[email protected]>> wrote:
Thomas D. wrote:
Maybe you are using other services like
"Sphinx" for search. Should
every
developer run and maintain a copy of Sphinx?
You should be able to get away with running one of
these on the dev
machine.
Just replicate over from prod periodically and
have each developer hit
this
instance. It is less likely that every developer
needs his/her own search
server.
Thomas D. wrote:
- Maybe you are working on an intranet
application, which requires
authorization. You will authorize against a
LDAP system. Should every
developer run and maintain a local LDAP service?
I haven't approached this regarding LDAP so I
can't comment.
Thomas D. wrote:
- In real applications, you will have multiple
entry points (website,
API
access...). Do you think every developer can
run and maintain these
things
locally?
Assuming this is all in your scm and deployed the
same way, I see no
reason
not to have all of this working on each
developer's instance. We run the
main web application, public api, and cli scripts
from the same
Zend_Application instance w/ Zend_Config. You
don't need ZF to do this
but
ZF makes it easy and organized.
Thomas D. wrote:
Your dummy data may also run out of date
I suggest a weekly dump, but depending on your
app, dummy data may
suffice.
Sorry to say it, but, it depends.
Thomas D. wrote:
Maybe your application is a shop system, your
data contains credit card
numbers and other sensible information. Do you
want that every developer
has access to these data? ;)
Are you really storing the full credit card
number? If so, the dump isn't
the problem. You aren't PCI compliant in this
case. Last 4 is OK. Even
with
that, I don't see the need to transfer the real
last-4 numbers to dev
instances. Those can easily be mocked. This is a
good reminder of why I'm
glad I no longer deal with e-commerce data.
Thomas D. wrote:
- Logging. Your application will generate many
log files.
Syslog is your friend and it is available by
default. With ZF, you can
switch between logging to syslog/file based on
environment if you like;
however, I like syslog.
Thomas D. wrote:
But you won't want that your developers sends
out test mails to real
users.
Filter the email address to be an internal one
before sending or write a
mock smtp adapter that simply logs the intended
recipient and the email
as
it would have been sent to a file.
Thomas D. wrote:
Should every developer run and maintain a
local mail server?
Not if you take the above advice.
-----
--
Wil Moore III
Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/Team-Development-tp2316451p2317664.html
Sent from the Zend Framework mailing list archive
at Nabble.com.
