I am using TYPO3 SURF to deploy my application. I added "LocalConfiguration.php" to my .gitignore. So everytime I push and deploy, the config file is missing from the live server and I have to go through the install tool again.
What is the best way to fix this ?
Include your LocalConfiguration.php in your versioning and deployment. Use a configuration switch to have different configuration values on different systems (e.g. development vs production). Here are some ways how to do it: Good practices in TYPO3 projects #3 Use a configuration switch mechanism
You might want to copy the LocalConfiguration.php file into your shared folder and create a symlink from your release folder to that file.
https://docs.typo3.org/other/typo3/surf/2.0/en-us/Examples/TYPO3/Index.html
Related
I am currently developing a PHP application using JetBrains PhpStorm. This applications contains several .htaccess files.
As there is right now no automated deployment process for this application I am using the "Upload to..." feature in PhpStorm. Using this feature the application is deployed to several servers.
The .htaccess files in my application need to have different content on different servers (staging systems vs production etc.). Unfortunately, so far I have not found a way to manage this reliably and have repeatedly overwritten .htaccess files with versions which are not suitable for the server I am deploying to.
Is there a way to make PhpStorm transform my .htaccess file before it is deployed? Or could I maybe define different versions of the same file for different servers?
The .htaccess files on each server are symlinks to the specified htaccess file in a folder. In this folder you have all your htaccess files from all servers. You skip the upload of the .htaccess files in PhpStorm, but you can change and deploy the files in the htaccess folder.
If you are able to create symlinks for htaccess files on your server, then this solution should work. It's not a clean solution, but better then wrong htaccess files on a server.
Hi and thank you for reading this!
I have two computers in my office LAN: One very powerful PC which i use most of the time for development and a notebook.
Now i would like to share all eclipse projects between these two devices (for example manually sync and then switch to the notebook). I don't need them to be availalbe in a cloud or something. I have also a NAS (network attached storage) which is always running.
Is it possible to synchronize all my projects? The main problem: complexity...
I use multible eclipse installations with multible addons like Aptana
Studio, SpringSource Tool Suite, Maven, Git, ...
Most Projects are Java EE, built with maven (different maven goals like jetty or tomcat)
Some projects use git for teamwork (with some external partners)
Some Projects use my own project-builders (external programs)
I use multible workspaces (i use different workspaces for different customers which include different projects)
Some projects are inside an eclipse workspace and some are outside
My current solution is to use a file syncronization program which syncs my whole "Projects" Folder (the root for my whole working-life) to a folder inside my NAS (manual sync - not on file change or schedule). The problem with this approach: I have to synch over 100000 files. This takes 20 minutes only to analyze what has changed. And when i open eclipse one time and manipulate one static html file, eclipse changes over 2000 files (most of them are in the .metadata folder)...
I'm open to every solution. Do i have to change the structure of my project setups? Do i have to use another sync solution? Or is it just not possible? Do i have to use an cloud store solution? Would this affect projects which already use git?
Thank you for ANY reply!!!!!
best regards!
Manuel
Indeed it is possible. How about using git for this scenario? You could create a bare repository on the NAS for those projects that shouldn't be published.
I guess if you deal with source code and really a lot of files this might be the best strategy to do this efficiently and secure (in terms of get-out-what-you-put-in).
I've decided to use the FreeFileSync tool from http://sourceforge.net/projects/freefilesync/
There is some effort to configure it to ignore some files and folders, but the tool provides nice filter possibilities. Configuring these filters can be very time consuming but they're working fine :)
Thank's for all your help!
At my company, we use Weblogic (depending upon the installation anywhere between versions 6.1 to 11g).
Right now, we embed environment specific variables into our ears, jars, and wars. This even includes the weblogic.xml file where we have something like this:
<working-dir>/opt/bea/wl61/server/domains/deploy/prod3/temp/work</working-dir>
That means we have to rebuild the same jars, ears, and wars for each and every environment. And, if there's a change in the environment, we have to rebuild and redeploy the wars, ears, and jars. You can imagine the issues and problems we have with build and release management (which is my job).
At my last position, we used JBoss, and somehow were able to create generic and deployable ears. I would have Hudson build an ear that the developers could use for their testing. This same ear could then be passed to our QA team in their environment, to UAT, staging, and into production.
We could do this amazing feat because we configured JBoss to look for properties files OUTSIDE or the ear itself. There was a config directory that was a sibling to the deploy directory that contained any needed properties files. Is it possible to setup Weblogic to do the same thing?
We need a way to do this with minimal code changes. I've already examined the source, and we don't specify the directory name when we specify loading the values in the properties files. Therefore, we might be able to do this with some sort of CLASSPATH idea.
I understand that these properties must live somewhere, but I would prefer if it could be configured in the environment, and maybe done by having the path relative to the deploy directory. I want to use the same ear, jar, and war files no matter what system you are on: Windows PC desktop, Linux, Mac, or Solaris server.
The toughest issue will be our weblogic.xml embedded path. Can that path be relative to the deploy directory and not from the root of the system?
As I stated before, I'm the build manager, so as far as everyone is concerned, this is my headache, and not their problem. If deployments don't go well, the Finger 'o Blame can point directly at me.
In order to get this to done I have to be able to find a solution that's simple for us to implement. We can't rewrite everything and change everything around. Otherwise, I can't get the other teams to do this. After all, it's my issue and not theirs. We need something with minimal coding changes (preferably none) and minimal changes in our Weblogic setup. I want something that in Version 3.4 of our software, we do it the old fashion environment specific way, but in Version 3.5, we can deploy in an environmentally neutral way and do that with minimal changes in our deployment environment.
I can feel your pain - I went through the same process at a couple of companies. You have a couple of options that would be a significant improvement from your current setup:
1) Modify the CLASSPATH to use an external directory / properties file that overrides everything that is in the ear file. This is easy to implement but can get out of hand without the proper standards/governance.
2) Use deployment plans to define environment specific variables. However, deployment plans were not introduced until the WebLogic 9.2.
3) Roll all of your environment specific files in to its own jar. All environments would be pointing to the same file but it would be building out different contents based on your build process. Advantages - Single file that contains all the props, easy to move, etc. Disadvantages - Cannot change properties on the fly and force a reload from the JVM.
There may be other options based on the repository. IMHO, all of these work more or less the same - It's the process and enforcing it that prevents issues.
I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html
What are good ways of dealing with the issues surrounding plugin code that interacts with outside system?
To give a concrete and representative example, suppose I would like to use Subversion and Eclipse to develop plugins for WordPress. The main code body of WordPress is installed on the webserver, and the plugin code needs to be available in a subdirectory of that server.
I could see how you could simply checkout a copy of your code directly under the web directory on a development machine, but how would you also then integrate this with the IDE?
I am making the assumption here that all the code for the plugin is located under a single directory.
Do most people just add the plugin as a project in an IDE and then place the working folder for the project wherever the 'main' software system wants it to be? Or do people use some kind of symlinks to their home directory?
Short answer - I do have my development and production servers check out the appropriate directories directly from SVN.
For your example:
Develop on the IDE as you would normally, then, when you're ready to test, check in to your local repository. Your development webserver can then have that directory checked out and you can easily test.
Once you're ready for production, merge the change into the production branch, and do an svn update on the production webserver.
Where I work some folks like to use the FileSync Plugin for Eclipse for this purpose, though I have seen some oddities with that plugin where files in the target directory occasionally go missing. The whole structure is:
Ant task to create target directory at desired location (via copy commands, mostly)
FileSync Plugin configured to keep files in sync between development location and target location as you code (sync the Eclipse output folder to a location in the Web server's classpath, etc.)
Of course, symlinks may work better on systems that have good support for symlinks :-)
To me, adding a symlink pointing to your development folder seems like a tidy solution to the problem.
If the main project is on a different machine/webserver, you could use something like sshfs to mount your development directory into the right place on the webserver.