RAD and multiple workspace

Question:

Hi Angel,  we have developers working in multiple branches and they want to switch branches and test their code. How can RAD work with multiple workspaces in WCS toolkit?

Rational Application Developer(RAD) as it is build with eclipse has the capabilities of changing workspaces.

RAD (when deployed as a toolkit for commerce) does accept the '-data' flag to specify a workspace, in fact it is always specified.

https://www.ibm.com/support/knowledgecenter/en/SSRTLW_9.1.1/org.eclipse.platform.doc.user/tasks/running_eclipse.htm

The startup script:

w:\wcde_\bin\StartWCToolkit.bat

has a line  that always specify the -data flag.

But one thing to keep in mind is that many of the scripts for Commerce are bound to use the w:\wcde_\workspace directory. Using a different workspace might put you in a unsupported enviroment, that statement goes as far as making changing to the value of the -data variable or making RAD load a different workspace.

In any approach you will need to stop the workspace and stop the server, at the very minimum. That is because GIT or you will replace the files that the server is using, which are hold in the workspace.

If you want to still use multiple workspace, one approach that I can suggest is to.

1) stop the server

2) close RAD,

3) make a copy of the current w:\wcde_\workspace to w:\wcde_\workspace_branch1 (this will take significant time)

When wanting to switch branch:

4) rename the current w:\wcde_\workspace to w:\wcde_\workspace_master

5) rename the w:\wcde_\workspace_branch1 to w:\wcde_\workspace

6) start RAD the traditional way and the server

This can be time consuming if you don't have a powerful computer, because starting the server and RAD are quite timely.

With good habits the activities can help to keep everything in sync without having your enviroment getting corrupted by the constant replacing of branches that eGIT allows, unknowingly if the server is up or down.

Git and IBM WCS workspace

Having been a developer for RAD and Eclipse, and now a SME for IBM Commerce Toolkit in the IBM consultant community. I am often asked what is the better setup for developers when working with Git.

There is not one approach that works for everyone, each have Pro and Cons. For Git usage I suggest and advocate for a separate workspace and repository, specially if you are using git-flow or any other approach where you will be switching branches often.

## Having a workspace separate from the repo:

- workspace dir: w:\wcde\workspace

- repository: c:\gitRepo

Pro:

1) Less workspace corruptions

2) Ease of `git pull`

3) Less Git conflicts/merges (as developers can pull content from GIT any time)

4) very easy to explain to developers where git repo is vs workspace

5) Adaptable for entire workspace check in or only delta check-ins

Con:

1) Developers have to download a separate tool for merges (beyond compare is recommended)

2) Deleted files in the repo may not always be deleted by the developers

3) Developers can forget to check in files

## Having a workspace attach to git

- workspace dir: w:\wcde\workspace

- repository: w:\wcde\workspace

Pro:

1) Easy to keep in sync with git

2) Deleted files will be removed during pulls and merges

3) No need for a separate compare tool

Con:

1) Need to setup .git-ignore rules

2) In the past eGit performance and bugs have had some troubles

3) If developers swtich branches often, can cause workspace corruption, if the server is up

4) Merge issues can easily cause workspace corruption

A new command to figure out ports

Recently in a project as we were doing the setup of the system, our hosting provider made a typo in one of the MANY ports that our solution uses and it cause a lot of confussion.

When creating the VIP (Virtual IPs) and ports mapping and the ports got flipped. Our hosting provider gave us a document saying this are your servers:

| IP | server service |
| -- | -- |
| 10.2.3.120 | VIP for live |
| 10.2.3.121 | VIP for  auth  |
| 192.168.1.140 | IP for live |
| 192.168.1.141 | IP for  auth  |

But we found out it was reversed, `.120` was auth and `.121` was live.

So after a lot arguing and a lot of hours of explaining what happened, how to test, and reporting to people.

I had the need to find a way to bring down the server and effectively test  that we are hitting a particular server in a specific port, not through the ports that are used by the server and services because sometimes they may not necessarily tell me if I am hitting auth. My options:
- Check the access log in the web server
- Create different data in auth and live (a user or a product that exists in auth but not in live)
- Enable accesslog trace in the app server

Find a way to test without the app server layer?

Solution: 

From Auth:
1) logon to auth at 192.168.1.141
2) `nc -l 5001`

From a client try:
3) http://10.2.3.120:5000

4) in auth, check the output of the `nc` command