Installations
Version Control Guide
We use both Subversion and Git for version control.
A crashcourse of our Subversion versioning processes can be
found in the
Subversion
Guide.
A crashcourse of our Git Versioning processes can be found
in the
Git Guide.
Development Process
A basic workflow of our Redmine tasks can be found
here.
jndi.xml File Setup
Update FullCountDS entry in jndi.xml files for tests in all
projects to the following:
<entry key="jdbc/FullCountDS">
<bean
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property
name="driverClassName"
value="oracle.jdbc.driver.OracleDriver"/>
<property name="url"
value="jdbc:oracle:thin:@localhost:1521/xepdb1"/>
<property
name="username" value="fc_user"/>
<property
name="password" value="fc_user"/>
</bean>
</entry>
This will only be a local change. Never commit these changes
to a branch.
Building and Running via Maven and Tomcat
In order to run our application locally, you first need to
start tomcat. Open command prompt and enter “startup”. Tomcat will start to
boot up and, in a few minutes, will be ready to use. To start your project,
right click on the project in Eclipse, click Run As -> Maven Clean. Once
this completes, right click on the project and click Run As -> Maven
Install. This will compile the code, run all of our unit tests, and create a
WAR file for our tomcat server to run.
NOTE: Only our web apps will run on Tomcat. Other applications, like
at-fullcount-model, at-maven-plugins, tools, etc. will not run on Tomcat.
Remote Debugging with Tomcat
To start Tomcat with remote debugging, open command prompt
and enter “catalina jpda start”. This will allow you to use breakpoints in
Eclipse to test your Java code. To create a breakpoint in Eclipse, double click
to the left of the line number that you want to investigate. This will pause
the code execution and allow you to look at variable values and step through
the code as it executes.
Deploying Builds to the Development Server
For some tasks, we need to deploy our local builds to dev
(development server) for testing purposes. Examples of this would be receipt
testing, print server testing, scheduled report testing, etc.
Before proceeding, ensure you send a message to the
development team asking if anyone is using the application you’re about to
replace. If no one is, then you can connect to tomcatdev01.fullcount.net on
PuTTy and WinSCP.
First, on PuTTy, run the command: sudo /sbin/service
Application_Name stop
Replace “Application_Name” with the application you want to
replace. This could be POSWebApplication, backoffice,
ResidentSelfServicePortal, etc. (a list of these can be found
here).
Next, in WinSCP find the application you want to replace on
dev and go to its “wars” directory.
(/srv/tomcat/instances/<application>/wars) Replace the war that is
currently there with your own war. Ensure that your war is named exactly the
same as the existing war.
After that, navigate to the “webapps” file in your project
on dev and delete everything under it. This ensures that the application will
be rebuilt when we restart the project. Lastly, go back to PuTTy and enter the
following command: sudo /sbin/service Application_Name start
Your local build of this project is now running on dev. Test
away!
Running dev.portal.fullcount.net on a POS Terminal
When making changes to our POSWebApplication project, we may
want to test those changes on a terminal. In order to do that, we need to
change the URL that the application is pointing to.
First,
plug in a keyboard to the terminal and hit Ctrl + Alt + F1. This opens the
command line on the terminal
Next,
log in as the “root” user (You can get the password from development or
systems personnel)
Now we
want to edit the /etc/sysconfig/fullcount file, so run the command: vi
/etc/sysconfig/fullcount
This
will open the config file in vim. Hit “i” to enter insert mode.
Edit
the “FC_APP_URL” to access “dev.portal.fullcount.net” instead of
“portal.fullcount.net” Press Esc to exit insert mode.
Enter
“:x” to save your changes and exit vim.
Enter systemctl
restart display-manager to restart the display manager.
The terminal is now running the POSWebApplication on dev. If
you want to change that application, follow the steps in the “Deploying Builds
to Development Server” section.
JUnit Testing
To ensure our code is correct, we write unit tests. These
tests run every time we Maven Install, which ensures that the code we’re
writing now doesn’t affect the results of other code in our codebase.
Historically, we haven’t tested consistently, so some projects don’t have a lot
of tests (POSWebApplication), while other projects have thousands of tests
(at-fullcount-model).
In general, when we write Java code, we will write unit tests for that code. To
learn how to write JUnit tests, take a look at the
Junit User Guide.
In order to run a test you’ve written in Eclipse, you can right click on the
test declaration and click Run As -> JUnit Test. You can also run all the
tests in the class by right clicking between tests and clicking Run As ->
JUnit Test.
TROUBLESHOOTING – You can run into a problem where, when you
try to run a test, a popup says “No tests found with JUnit 5” even though there
are valid JUnit 5 tests in the class. To fix this problem, try the following
steps:
Ensure
the test(s) you’re trying to run are annotated with @Test or
@ParameterizedTest
Ensure
the @Test annotation is imported from: org.junit.jupiter.api.Test
Go to
Project -> Clean, select the project you’re working on, and click Clean
Troubleshooting
You can run into a multitude of problems and errors when
programming. Here are a few common ones at FullCount and how to solve them.
After
Maven Installing a project in Eclipse, you receive the following error - Failed
to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.2:redeploy
(tomcat-deploy) on project backoffice: Cannot invoke Tomcat manager:
Connection refused: connect -> [Help 1]
This
one is simple: Eclipse is trying to deploy a web application to Tomcat,
but Tomcat isn’t running! To start Tomcat, open up Command Prompt and
enter “startup”. This will start Tomcat, and after its done deploying,
you can run your project again.
The
application you’re trying to build is failing because the compiler can’t
find classes/methods in other projects.
First,
ensure the pom.xml file of your project has the correct version of the
project you’re trying to access functionality from (version numbers are
also found in the pom.xml file).
Next,
try to clean the project. Go to Project -> Clean. Select your project
and the project you’re trying to access and see if that fixes the issue.
You can also try to Maven Clean your project.
If
none of these solutions work, you may need to do a Maven Update. Right
click on your project in the Project Explorer, click Maven -> Update
Projects… Only select your project and hit ok and see if that fixes the
issue.
When
trying to build at-fullcount-model you run into database errors (such as
NoSuchColumnException), and it’s a little while after the central-hosted
release.
Turning Code in for Review
After you’ve made and tested all your code changes to ensure
they’re working, you’re ready to turn in your code for review. First, go
through the
developer
checklist. The checklist helps us catch simple mistakes and helps us ensure
we’ve done everything before turning our code in for review. After that has
been completed, edit the Redmine task so the Status is “Feedback,” the Assignee
is the designated code reviewer, and Released To is “Local Machine.” This
combination of properties is how we tell the code reviewer that our code is
ready to be reviewed.
The “designated code reviewer” can vary depending on what
project you’re working on. If you’re working in self-service, customer-portal,
or authorization, turn your code into Adam. However, if you’re working on any
other project, turn your code into Susan. When in doubt, turn your code into
Susan.
Release Cycle
FullCount has a monthly release schedule. We will release on
the second Tuesday of every month to central-hosted communities and the third
Tuesday of every month to remote-hosted communities.
We have a developer deadline of the Wednesday before our
central-hosted release for tasks to be turned into the designated code
reviewer. This gives them time to review tasks and give feedback to the
developer responsible for writing the code. Preferably, developers will turn in
code throughout the month, rather than turning in all the code they wrote for
the month on that Wednesday.
This deadline is flexible; if there is an issue that must be
released this month and it isn’t quite done by the deadline, that’s fine, but
try to get it finished ASAP.
Release Meeting Presentations
New Baseline Process
Helpful Resources