Best practice for developing with Liferay

[Lior Hadaya, modifié il y a 12 années.]

Hi,
We are in the process of starting to work with Liferay Portal in our development group.
I am looking for some input from experienced Liferay developers on what is the recommended way to work with Liferay as far as machines set up.
From my understanding, every developer should install Tomcat (or a different app server) & the Liferay SDK on their local machine in order to develop portlets/themes/etc. Is that correct? is there anything else that should be installed on the developers machine?

Also, how many Liferay Portal machines is it best to set up? One per development team or one per developer? maybe one server for several teams is enough?
Is there any significance to how developers deploy their products on the server? can they just deploy at will or is it best to have a daily deployment process?

Thanks,
Lior

[Tejas Kanani, modifié il y a 12 années.]

Check out below link. It has many useful resources which might help you.

http://www.liferay.com/documentation/liferay-portal/6.1/community-resources

[Lior Hadaya, modifié il y a 12 années.]

Thanks, I've looked over some of the links and they are usefull but I don't really see any relevance to my questions.

[Prakash Khanchandani, modifié il y a 12 années.]

I am assuming Liferay CE (for EE you would have to have a server license (for production deployment), and a developer license for developing with EE)
1) For development (faster) purpose you can have Eclipse IDE with Liferay IDE plugin installed. For all the developer machines.
2) So that means every developer will have a tomcat bundled liferay configured for their respective IDE.
3) Developers can deploy their product by creating a WAR file and then deploying it directly to the deploy folder or through Control panel plugins installation (recommended).

Hope this helps

[Lior Hadaya, modifié il y a 12 années.]

Hi Prakash, thank you for your reply.
Sorry for not mentioning it, but I am talking about EE.
If I understand correctly, it's enough to have one server installed with Liferay that all developers will use in ourder to deploy their products, right?
Is there any benifit to having one server per development team, instead of one server for all teams?

I read that it's possible to use the Liferay IDE plugin with a remote server (Remote feature), do you know if it's recommened or is it best for each developer to install liferay bundled with tomcat on their local machine

Thanks

[David H Nebinger, modifié il y a 12 années.]

Lior Hadaya:

If I understand correctly, it's enough to have one server installed with Liferay that all developers will use in ourder to deploy their products, right?

It is enough, but would mean that outages/issues w/ the environment will be a blocker for the developers. I'd suggest allowing each one to have their own local liferay server to remove these blockers.

Is there any benifit to having one server per development team, instead of one server for all teams?

You'll need a server to do the combined testing of the various plugins being developed.

I read that it's possible to use the Liferay IDE plugin with a remote server (Remote feature), do you know if it's recommened or is it best for each developer to install liferay bundled with tomcat on their local machine

You can do the remote option, but may run into conflicts when a developer wants to run in debug mode, test a plugin that is not really ready for deployment, etc.

[Lior Hadaya, modifié il y a 12 années.]

Hi David, thanks for replying.

I see your point as to why it's best for developers to install their own liferay bundle on their local machines.
I didn't take the database into account, thanks for pointing that out. You recommended installing mySql for each dev, is using the default hsql DB for the devs environment (not for production) not recommended?

I'd recommend having one or more 'build masters' that are responsible for doing builds to the test machines. Do the builds from stable boxes that are consistent w/ each other (run same version of jdk, have same dir structures, etc.). They do the builds and deploy to the test server from those boxes.

The 'build master' concept defintely makes sense. What do you mean by stable boxes?

Deployment of Liferay plugins can still be tricky when there are version dependencies; i.e. my portlet needs version 1.3 of the EXT plugin while yours only uses version 1.2... During deployment time, the right version of the EXT plugin needs to be there for both of us, but if a break occurs who gets to fix it?

So the solution for this is to have someone responsible for maintaining the Liferay test server with the most up-to-date version of all components?

Thanks

[David H Nebinger, modifié il y a 12 années.]

Lior Hadaya:

I didn't take the database into account, thanks for pointing that out. You recommended installing mySql for each dev, is using the default hsql DB for the devs environment (not for production) not recommended?

The HSQL database is really only good for doing the liferay demos; I wouldn't use it for anything outside of that, but admittedly that's my own personal bias. Postgres or any of the other supported databases should be used. Mysql and postgres are free, so you can install local dev databases.

The biggest reason for the separate databases is that page layouts, portlet placements, etc. are all stored in the database. If you're using a shared database for the devs, they'll see a lot of the 'portlet has been undeployed' messages, theme not available, etc., if they didn't have all of every one else's plugins deployed to their local system. And for testing/debugging, developers might not want to have everything deployed locally.

The 'build master' concept defintely makes sense. What do you mean by stable boxes?

Well, stable in that they are somewhat controlled. Devs may want to use different versions of ant, different versions of the JDK, etc. By using a 'stable' box for the builds for deployment to the test system you'll know what versions of everything are used for test deployment and eventual prod deployment.

For example, we have some devs that use Macs or Linux for their desktop, but our test and production systems are (unfortunately) running windows. We have a 'stable' build system that is also windows that we do our builds on for test and prod deployment. I know this is an extreme case, but our plan is to ensure that what goes to test and prod is compiled and built under the same kind of environment and rules out local system differences between developers.

So the solution for this is to have someone responsible for maintaining the Liferay test server with the most up-to-date version of all components?

Sure. In the end the goal of the SCM is to ensure that you get repeatable consistent builds and that deployments to the test and prod systems have as few issues as possible. Designating a 'build master' will give your SCM that warm and fuzzy feeling...

[jamel ben ahmed, modifié il y a 7 années.]

Hello everyone
Assume that each dev has on its local post (Mysql, tomcat and liferay).
How you will do for the versioning of the codes at the declipse level as the creation of a module or theme.
Also for work that is done directly on liferay like components and pages ??

[Javin Paul, modifié il y a 12 années.]

Prakash Khanchandani:

I am assuming Liferay CE (for EE you would have to have a server license (for production deployment), and a developer license for developing with EE)
1) For development (faster) purpose you can have Eclipse IDE with Liferay IDE plugin installed. For all the developer machines.
2) So that means every developer will have a tomcat bundled liferay configured for their respective IDE.
3) Developers can deploy their product by creating a WAR file and then deploying it directly to the deploy folder or through Control panel plugins installation (recommended).

Hope this helps

Thanks Prakash, Indeed these are very helpful, especially beginners like me.


Java Tutorial

[jamel ben ahmed, modifié il y a 7 années.]

Hello everyone
Assume that each dev has on its local post (Mysql, tomcat and liferay).
How you will do for the versioning of the codes at the declipse level as the creation of a module or theme.
Also for work that is done directly on liferay like components and pages ??

[David H Nebinger, modifié il y a 12 années.]

Lior Hadaya:

From my understanding, every developer should install Tomcat (or a different app server) & the Liferay SDK on their local machine in order to develop portlets/themes/etc. Is that correct? is there anything else that should be installed on the developers machine?

By tomcat you're meaning a Liferay bundle, I hope. Devs will work better if they can control their own bundle and not get hung up due to work ongoing by others.

You may also want to consider local MySQL databases for unit testing, for pretty much the same reason.

Also, how many Liferay Portal machines is it best to set up? One per development team or one per developer? maybe one server for several teams is enough? Is there any significance to how developers deploy their products on the server? can they just deploy at will or is it best to have a daily deployment process?

A per-dev local liferay bundle will allow the devs to proceed independently and not impact each other, so I'd recommend that route.

This can make the SCM process more fun. I'd recommend having one or more 'build masters' that are responsible for doing builds to the test machines. Do the builds from stable boxes that are consistent w/ each other (run same version of jdk, have same dir structures, etc.). They do the builds and deploy to the test server from those boxes.

If you don't use the build master concept, your test server is going to turn into a free-for-all with everyone making changes willy nilly and, when there are problems w/ the Liferay server, no one will step up and take blame...

Deployment of Liferay plugins can still be tricky when there are version dependencies; i.e. my portlet needs version 1.3 of the EXT plugin while yours only uses version 1.2... During deployment time, the right version of the EXT plugin needs to be there for both of us, but if a break occurs who gets to fix it?