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

Re: PHP developers workflow discussion

----- Original Message -----
> 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
> - but is that enough? Would that be even maintainable?

As someone who recently rewrote the Drupal/Wordpress quikcstarts I can give some feedback I've heard from people opening bugs against me.

There are two important sets of users:

1) Those who want to use drupal/wordpress more like an admin
2) Those who are more comfortable dealing with it more like a developer

Group #1 wants the content in the data dir, and they expect Wordpress "to just work".  Without shared storage though, scaling those apps is hard because the data dirs have to be synced, and then replicated.  Down the road, we want this to just work with scaling but we're not there yet

Group #2 wants to check the code in and push changes out, they're ok with doing some hacking to get there.  For these guys, if they check their plugins in they can scale their apps, but they lose the web experience (mostly)

However, both of these frameworks have different requirements for the data dir.  What might be nice here is some sort of magic in the cartridge - perhaps a ".openshift-links" marker file in a directory that will autosymlink an ${OPENSHIFT_DATA_DIR} equivalent at build time.  For Wordpress this could "almost" work - we might still have to add some more logic.  This starts to stray dangerously into proscribing a format, but the alternative is to start hacking the same code into the build scripts.  The alternative might be a helper that lives in the build hook that autosymlinks dirs.  

> 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.

As a note, we've had a bunch of discussions about this previously and this is definitely something we'd like to implement in both the clients and the deploy model.  We've so far discussed the possibility of a "no restart git deploy", and there's a client code branch that does this transparently in the background:


In this model the idea was that you could start the client up, which watches a directory, then makes a commit everytime you save onto a branch.  The gear would be in a "no restart on deploy" mode that would take incoming commits and lay them down to disk.  Once you're done, you get to decide whether to commit or not, and the client would tell openshift to go back into "regular mode".

> =
> 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)
An interesting idea - certainly this seems reasonable for a user to request this sort of config (copy to a non-bare git repo on the server).  Has some potential headaches - if you're using SFTP or rsync though on the client, the question comes down to whether you want to avoid git locally, or "hide" git from the user.  There are a hundred ways to do deploys and the biggest worry I'd have is that we give too many options.

So the question for you is - do PHP developers not want to see Git?  Should they see Git?  Is Git inevitably going to trickle down into every facet of the programming world over time?  Should we be a frontend to Git?  All of those questions may change over the next 3-5 years, but it'd be good to get a coherent perspective of whether we should hide Git from PHP developers (because it scares them) or ease them into it (so they are ready for where the industry is going).

> - 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.
> - Vojtech
> ---
> Vojtech Vitek
> Red Hat, Inc.
> Brno, Czech Rep.
> GSM: +420608260892
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

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