I'm developing a distributed environment, mostly in PHP.
A lot of the projects that I have share some of the same code. For example my logging code (based on log4php but with some custom additions).
I can just copy-paste this code in every project, but naturally, if I change anything in it I need to re-paste it everywhere and 'hope' it doesn't change anything.
Obviously not a good way.
Now, I was wondering: what is the best and simplest way of sharing this code?
I'm hoping there is something as easy as making your own private PEAR-like channel? Do people do this for this use case? Or is there an ever easier way? I rather not start with inter-dependent repositories etc. If it matters though, I use Mercurial for versioning.
Thanks all.
Perhaps the best way (I am using too) is to host the common code in a versioning system such as Git or Mercurial or SVN and checkout this code in each related project. As long such a project does not have updates you can continue to work on your common code. In the case you want to touch a project again that utilizes the common code, you need to perform a source code update or pull. Then you update your project sources according to the changes of the common source base.
What about include_path PHP directive?
Just add include_path, for example /usr/share/php5/
and include your file like yourfile.php from each project
Use Git or Mercurial for that. In both of them, you can create sub-modules or sub-repositories.
http://kernel.org/pub/software/scm/git/docs/git-submodule.html
https://www.mercurial-scm.org/wiki/Subrepository
Related
I have looked and looked all over to find a way to make something similar to PhpBB's automod system they use for their software.
I cannot seem to find anything similar to this with the whole xml find and replace code updater and mod installer.
I may just be typing in the wrong keywords in Google, but does anyone know of any system like this available before I start trying to make my own?
EDIT: I mean more like a code updater. For example find and replaces in a php file.
FIND:
?>
ADD BEFORE:
echo "this is text added before the ?>";
I realize this could be done with str_replace but there is surely a system out there that already does this reliably.
The reason that a system doesn't exist outside of phpBB is because it's an incredibly poor way to manage modifications. Your question does not make it clear what you want to gain from this, but since it is your own code, you should definitely not look to copy something so awful.
For “patching” code
If you want the ability to apply updates to your code, then you should look at handling it through version control. For instance, you could develop and test in a local git repository, and once you are happy, push the changes to the server. You have many options here from a basic update script to a fully-fledged Continuous Integration solution.
phpBB have implemented a solution for patching code on your live site via a Web interface, which has many issues with security, verifiability and maintainability among others.
For exposing “plugin” functionality
If you want the ability to register plugins in parts of your code, then you should architect your code as such to allow it to be handled easily. Wordpress, MediaWiki and other projects can help you write such a structure.
I have 3 PHP projects using the CodeIgniter framework which share some exact same files such as models libraries and controllers. What's the best way I could share these files across without having to keep in sync and update the same files across?
In linux I thought of using dynamic links and extract these files to a central place but that kind of breaks our version control and would create portability issues.
Another way perhaps to use unison on these files across projects
I'm assuming that's a common problem, what are common approaches?
Separate them into a module, and use something like composer.
http://getcomposer.org/
Or just put them in a separate SCM.
One thing you can do:
Put all the shared code in libraries, helpers and models and place this in a separate folder. Then use:
$this->load->add_package_path('shared location');
Also take a look here: http://codeigniter.com/user_guide/libraries/loader.html , under application packages.
This works for most of the stuff, except controllers.
Use version control! In svn you can use externals, git has submodules or subtrees.
You don't want to use hardlinks, you'll run into weird issues like updating one project influences another project ("that I haven't touched in weeks").
The code can be in two physical places but shared under version control. There will always be only one authorative copy, namely the one in your version system. All physical copies are derivatives. It's important to see that you have control over when you update the code of a specific project, so a change at one point doesn't immediately break another project in case you made a mistake.
If you do want to catch these kinds of errors, set up a proper regression testing environment.
Sharing a development environment with another developer is also a big no. You don't want to have to wait till your colleague fixes a parse error that breaks the entire program. Each developer should have their own copy (checkout!) of a project and similarly each project should have their own copy (externaled) of shared code.
Seperate them into folders outside your project, then configure or include them in your projects.
Usually we will rewrite "autoloader" method for the project to find files in our new folders.
I have developed an application and now I would like to hire some programmers to work on several pieces of it to upgrade and tweak it.
I have read other questions/answers here but they are mainly about obfuscating the code which is something I do not want to do (as I need them to read it and tweak it).
What I'm basically asking is, what is the best way to structure my code so I will have to expose only what I have to?
A good example for me is a webapp called RightNow which I'm developing for at work, what they do is they let you play around with all the widgets (you can create/edit/remove any widget) but the core of the application is in folders I do not have permissions to.
After you do your coding on the widgets, you then 'deploy' the application and it goes live. I have no idea what the deployment actually does behind the scenes, but this is one practice (not sure if it's the best) which allows the application owner to have control over the core of the code but still allow development for it.
Is there a better way? what do you think?
First you can use a version control software like SVN for example.
and then you can have copies of the code, one for testing and one for the your programmer. When the programmer is done changes and tweaks, the testing code gets updated first and when the test are done the live application gets updated.
you can obfuscate your core classes(ones that you don't want to expose). and other developers can include and use them at the same project as long as you provide a nice api to your classes.
I have a need to create a library of Object Oriented PHP code that will see much reuse and aspires to be highly flexible and modular. Because of its independent nature I would like it to exist as its own SVN project.
I would like to be able to create a new web project, save it in SVN as its own separate project, and include within it the library project code as well. During this process, while coding the web application code and making commits, I may need to add a class to the library. I would like to be able to do so and commit those changes back to the libraries project code.
In light of all this I could manage the code in two ways
Commit the changes to the library back to a branch of its original base project code and make the branch name relevant to the web project I was using it with
Commit the changes to the library back to the original code, growing it in size regardless of any specific references that might exist.
I have two questions
How can I include this library project code into a new project yet not break the subversion functionality, i.e. allowing me to make changes to each project individually?
How I can keep the code synchronized? If I choose the first method of managing the library code I may want to grab changes from another branch and pull it in for use in another.
EDIT - I realize I can simply check out these projects individually and commit/update them individually as well, but then how can I include them together as a single project? To be more clear, how could I create a web project that includes the library code as a unified subversion project in consideration of the points I elaborated on above?
I think you can use svn:externals to achieve what you want. It will pull the library project into your website project and update it whenever you update your working copy. The only thing is you cannot commit back to the library in the same commit as you project as described in this question How do I checkin to local copy AND svn:externals subdirectories in one commit?.
Option #1 looks like the right way to go.
I think you should expect to keep separate branches of the API project for any of your sites that have site-specific modifications to the shared API. Of course, you don't need to create the branch upfront, just checkout the 'trunk' and make sure you branch before you commit any site-specific changes.
There are a couple of articles on branching/merging that I have used in the past that might help you out:
Streamed Lines: Branching Patterns for Parallel Software Development
MSDN Branching and Merging Primer
However, there are some aspects of your 'two questions' that are a bit confusing/concerning. Hopefully I'm misinterpretting what you've said, but keep the following in mind:
With your first question, I think you might be getting caught up on the physical location of the source code on your development machine and how your repositories will be structured (hint: treat the two separately).
In your second question, you mention specific references and it sounds like you might be thinking of making your API in some way dependent on the website source (hint: bad idea for an API).
I have a folder of PHP scripts, they are mostly utility scripts. How to share those scripts among different PHP applications so that reuse and deployment are easy?
I would have to package my app into an installer, and let the user install it.
I could put the lib and hardcode the include path, but that means I haven to change the PHP code every time i deploy the web application to a new customer. This is not desirable.
Another route I consider is to copy the lib to other apps, but still, since the lib is constantly updating, that means that I need to constantly do the copying, and this will introduce a lot of problems. I want an automated way to do this.
Edit: Some of the applications are Symfony, some are not.
You could create a PEAR package.
See Easy PEAR Package Creation for more information on how to do this.
This assumes that when you say anyone, you mean outside your immediate organisation.
Updated: You do not need to upload to a website to install the PEAR package. Just extract your archive into the pear folder to use in a PHP application.
Added: Why not create a new SVN repository for your library? Lets say you create a library called FOO. Inside the repostory you could use the folder heirachy of trunk\lib\foo. Your modules could then go into trunk\lib\foo\modules and have a file called trunk\lib\foo\libfoo.php. Now libfoo.php can include once or require once all the modules as required.
PHP now supports Phar archives. There's full documentation on php.net.
There's a complete tutorial on IBM website as well.
One neat thing you can do with Phar archives is package an entire application and distribute it that way.
http://php.net/phar
http://www.ibm.com/developerworks/opensource/library/os-php-5.3new4/index.html
Ahh, libraries...
There are two conflicting purposes here:
Sanity when updating scripts (ie. not breaking 10 other apps).
Keeping things in one organized logical place for developer efficiency.
I suggest you take a close look at git and git submodules
We use git submodules extensively for this very purpose. It allows the best of both worlds because shared scripts can be upgraded at will in any project, and then that change can be moved to the other projects (deliberately) when you have time to do so and test correctly.
Of course, you need to be using git to take advantage of submodules, but if you are not using git, and you start, you'll eventually wonder how you ever lived without it.
Edit: Since the original poster is using svn, consider using SVN Externals.
UPDATED:
you just have to put the lib in some place reachable by your apps (in a place where you can reach it via http or ftp or https or something else) and include it.
If you have to update it often you can package your library in a single phar file and you can then provide your client a function to pull the library from some remote path and update a parameter in their local configuration accordingly, like:
function updateLocalLibary(){
//read the remote library in a variable
$file= file_get_content($remoteLibraryRepository.$libraryPharFile);
//give it a unique name
$newLibraryName=$libraryPharFile."_".date('Ymdhsi');
//store the library it on a local file
file_put_content($localLibraryPath.$newLibraryName,$file);
//update the configuration, letting your app point to the new library
updateLatestLibraryPathInConfig($newLibraryName);
//possibly delete the old lib
}
In your include path then you don't have necesasrily to hardcode a path, you can include a parameter based on your config, like:
include( getLatestLibraryPathFromConfig() )
(you are responsible to secure the retrieval in order to let only your clients see the library)
Your conf can be in a db, so that when you call updateLibraryPathInConfig() you can perform an atomical operation and you are sure not to have client read dirty data.
The clients can then update their library as needed. They may even schedule regular updates.
There are a lot of options:
tar + ftp/scp
PEAR (see above #Wayne)
SVN
rsync
NFS
I recommend to use a continuous integration software (Atlassian Bamboo, CruiseControl); check out your repository, build a package, and then use rsync. Automatically.
You should also look into using namespace in order to avoid conflicts with other libraries you might use. pear is probably a good idea for the delivery method, however, you can just place it in the standard path /usr/share/php/, or any other place that is set as the include path in your php settings file.
Good question, and probably one that doesn't have a definite answer. You can basically pick between two different strategies for distributing your code: Either you put commonly used code in one place and let individual applications load from the same shared place, or you use a source-control-system to synchronise between local copies. They aren't mutually exclusive, so you'll often see both patterns in use at the same time.
Using the file system to share code
You can layer the include_path to create varying scopes of inclusion. The most obvious application of this pattern is a globally maintained PEAR repository and a local application. If your it-system consists of multiple applications that share a common set of libraries, you can add a layer in between these (a framework layer). If you structure the include_path such that the local paths come before the global paths, you can use this to make local overrides of files. This is a rather crude way to extend code, since it works per-file, but it can be useful in some cases.
Use source-control
Another strategy is to make a lot of local checkouts of a single shared repository. Some benefits over the layered-include-pattern is that you can make more fine grained local changes. It can be a bit of a challenge to manage the separation between application layers (infrastructure, framework, application). svn:externals can work, but has some limitations. It's also slightly more complicated to propagate global changes to all applications. An automated deployment process can help with that.