[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PHP developers workflow discussion



----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "Vojtech Vitek" <vvitek redhat com>
> Cc: dev lists openshift redhat com, "Mike McGrath" <mmcgrath redhat com>
> Sent: Monday, March 18, 2013 3:32:03 PM
> Subject: Re: PHP developers workflow discussion
> 
> 
> 
> ----- Original Message -----
> > ----- Original Message -----
> > > On Fri, 15 Mar 2013, Vojtech Vitek wrote:
> > > 
> > > > Hi,
> > > > this thread is meant to start discussion about the possible
> > > > improvements
> > > > for the PHP (and other interpreted scripting languages)
> > > > developers.
> > > >
> > > > 1) Self-modifying apps, built-in installers
> > > >
> > > > PHP frameworks often use the self-modifying functionality of
> > > > it's
> > > > own
> > > > source files. Not just for storing the application settings,
> > > > but
> > > > also
> > > > for updating/installing the functionality.
> > > >
> > > > As an example, both Wordpress/Drupal have built-in installers
> > > > that
> > > > can
> > > > be used via the administration; so the site admins are able to
> > > > update/install new plugins and themes on-the-fly.
> > > >
> > > > Normally, all the changes are made in the app's source code
> > > > itself:
> > > >  Drupal: app-root/repo/php/sites/*/{modules,themes}
> > > >  Wordpress: app-root/repo/php/wp-content/{plugins,themes}
> > > >
> > > > This is nothing we would like on OpenShift, right? Because
> > > > whenever
> > > > the Developer git pushes, these changes are all wiped out..
> > > >
> > > > So what's the workaround? They could probably use the
> > > > persistent
> > > > storage
> > > > (symlink the directories in git relatively to the
> > > > $OPENSHIFT_DATA_DIR),
> > > > - but is that enough? Would that be even maintainable?
> > > >
> > > 
> > > This use case doesn't sound like a developer use case to me.
> > >  This
> > > sounds
> > > like someone wanting to run software on openshift.  It's a subtle
> > > difference I know but this sounds a lot like someone just wanting
> > > to
> > > host
> > > their blog on OpenShift.
> > 
> > Not necessarily; let me describe the most common usecase for
> > Drupal:
> > - Developer installs the Drupal core
> > - Developer installs Drupal modules to bring new functionality
> >   (think of each module as library with it's own API and
> >   dependencies)
> > - Developer doesn't care about source code of any of the above,
> >   he just wants it running and up-to-date as a stable framework
> > - Developer creates new git repository (usually git submodule) in
> > the
> >   app-root/repo/php/sites/default/modules/ for each of his custom
> >   modules... and this is where the development happens
> > 
> > > 
> > > In that case I think OPENSHIFT_DATA_DIR is approperate *or* a
> > > community
> > > cartridge (which doesn't exist yet)
> > > 
> > > >
> > > > 2) SFTP to the app-root/repo/
> > > >
> > > >  - By the way, this is the default workflow used by the Zend
> > > >  Studio
> > > >    while developing the Zend apps on OpenShift right now..
> > > >
> > > > I've talked to many PHP developers about their feel and
> > > > satisfaction
> > > > with the OpenShift PaaS and most of them told me they really
> > > > hate
> > > > the
> > > > "slow" git push deployment.
> > > >
> > > > They can't develop on OpenShift as quickly as they're used to,
> > > > so
> > > > they're basically forced to use their own local Apache for
> > > > development.
> > > >
> > > > This is against the whole PaaS idea; and also far-away from the
> > > > ideal
> > > > test/production release management.. See
> > > > https://openshift.redhat.com/community/blogs/release-management-in-the-cloud
> > > >
> > > > What the PHP developers call for is usually the SFTP/FTP access
> > > > to
> > > > the app-root/repo/ directory using their favorite IDE to be
> > > > able
> > > > to make the changes on-the-fly. Why? The thing is, that PHP is
> > > > kind
> > > > of those "Try it and see if it works." languages.
> > > >
> > > > =
> > > >
> > > > So what comes to my mind to improve the usability for the PHP
> > > > developers
> > > > (and to be able to use PHP apps with self-modifying
> > > > functionality)
> > > > is:
> > > > - let them access the app-root/repo/ for development (well,
> > > > they
> > > > can
> > > >   do it right now, until they git push and wipe-out all the
> > > >   changes..)
> > > > - let them decide if the app-root/repo/ was git repository or
> > > > not
> > > > (means do not remove the .git/ metadata when cloning from bare
> > > > git
> > > > repo)
> > > > - let them git commit/push from that gear's repository using
> > > > SSH
> > > > - let them git commit/push from Web Console (as in advanced
> > > > Cloud
> > > > IDEs)
> > > > - let them do the above also using the popular Cloud IDEs (eg.
> > > > Cloud9)
> > > >
> > > >
> > > > We would need of course to think of the possible git conflicts
> > > > that
> > > > would come with the app-root/repo/ git repository. But in my
> > > > opinion,
> > > > this all would be wort it.
> > > >
> > > 
> > > We've talked a great deal about making the developer experience
> > > better and
> > > it's something we need to get back to after the cartridge format
> > > changes
> > > go down.
> > > 
> > > So, a couple of things.  They can always symlink
> > > app-root/repo/php
> > > somewhere (though as I understand it we should get rid of the
> > > /php
> > > at
> > > some
> > > point).
> > 
> > Yes, my plan for php cart v2 is to have the public dir changeable.
> 
> Can you elaborate on what your plan is there?  There have been
> several discussions about this - the last I heard here was a strong
> desire for the cart to infer the correct php directory based on the
> structure of the git repository.  There should be a default (which
> folks are pushing for to be www) for new repos, but when someone
> delivers a repo that has no php dir but index.php in the root, the
> cart should use the root as the php dir.  If there's a php/ or www/
> dir with index.php, then the cart would use php or www. If the cart
> can't determine, it would fall back to either an openshift marker or
> not.  Is that all feedback you've integrated, or are you earlier
> along.

The idea of having www/ as default public dir is far better than the
current php/ directory. The other alternative would be also public_html/
directory to which many users are used to from most Unix-like hostings.

Honestly, I didn't think of any advanced logic behind that to recognize
every possible use-case. My plan was to make the httpd.conf (or at least
part of that) changeable to the developers, so they can change the
default values, any additional directory mappings or Apache settings
themselves if they really need to.

The main idea is to give the Developers as much freedom as we can offer
them. Once we give them ability to change all server contexts
(meaning also server config and virtual hosts; not just directory context
and .htaccess), I think then we'll go for the win.

What we have in v1 cart gear now is:
./php-5.3/conf.d/openshift.conf (readonly)
<Directory "/var/lib/openshift/<USER>/app-root/runtime/repo//php">
  AllowOverride All
</Directory>

What I'd like to reach in v2 cart gear:
./app-root/conf.d/*.conf (writable by developers)

In the best scenario having the symlinks or Includes to the
./app-root/repo/.openshift/conf.d/* so every app can have it's Apache
specific *.conf settings in git.

The question is:
What are security considerations for not letting the developers touch
any of the Apache *.conf files? And is there anything we could not be
able to override (after the mentioned Include directive)?

- Vojtech
 
> 
> > 
> > > 
> > > Also, and the science here is extremely important, find one of
> > > your
> > > developers and have them time the difference between an rsync
> > > (which
> > > would
> > > work today) and a git push.  Then have them do the same with hot
> > > deploy
> > > and some other bits and report that info back to the list.
> > 
> > What I was referring to was not just about deploying the changes -
> > but rather about the on-the-fly development itself.
> > 
> > Developers want to use their favorite IDE, hit the hotkey to save
> > the changes and "see if it works" in the browser.. And once they
> > say "hey, it really works", then we can think of them doing any
> > "manual work" (say git commit/push).
> > 
> > Hot deploy doesn't help there either. It just speeds up the bad
> > development model. We want the PHP developers to u