We’re starting our very first project with Spring and java web stack. This project will be mainly about rewriting quite large ERP/CRM from Zend Framework to Java. Important factor in my question is that I come from php territory, where things (in terms of quality) tend to look different than in java world.
Fatcs:
- there will be 2-3 developers,
- at least one of developers uses Windows, rest uses Linux,
- there is one remote linux-based machine, which should handle test and production instances,
- after struggling with buggy legacy code, we want to introduce good programming and development practices (CI, tests, clean code and so on)
- client: internal, frequent business logic changes,
- scrum, daily deployments
What I want to achieve is good workflow on as many development stages as possible (coding -> commiting -> testing -> deploying). The problem is that I’ve never done this before, so I don’t know what are best practices to do this.
What I have so far is:
- developers code locally,
- there is
vagrantinstance on every development machine, managed bypuppet. It contains the samelinux,jenkinsandtomcatversions as production machine, - while coding, developer deploys to vagrant machine,
- after local merge to
testbranch,jenkinson vagrant handles tests, - when everything is fine, developer pushes commits and merges
jenkinson remote machine pulls commit fromtestbranch, runs tests and so on,- if everything looks green,
jenkinsdeploys totesttomcatinstance - Deployment to production is manual (altough it can be done using helping scripts) when business logic is tested by other divisions and everything looks fine to client.
Now, the real question: does above make any sense? Things that I’m not sure about:
- Remote machine: won’t there be any problems with two (or even three, as jenkins might need one) instances of same app on
tomcat? - Using
vagrantto develop onphpenvironment is just vise. Isn’t this overkill while using Tomcat? I mean, is there higher probability thattomcatwill act the same on every machine? - Is there sense of having local
jenkinson vagrant?
Welcome to the world of CI! (may I suggest this book? It really helped me get my head around all of this CI practice)
Remote machine: won’t there be any problems with two (or even three, as jenkins might need one) instances of same app on tomcat?
In my experience: Yes. But I’m sure they’re caused by my own lack of knowledge/experience. My testing environment is a crappy old pc and system resources are scarce. I’ve automated almost all steps from git push to app deployment but every once in a while some .jar doesn’t get released by Tomcat, and I get out of memory errors from my builds on Jenkins. (I’ve already been here, here, here, here and even here).
You might probably have to configure your Jenkins project in such a way that it should undeploy the current app running on Tomcat, restart Tomcat, build the new one and deploy that new build.
Using vagrant to develop on php environment is just vise. Isn’t this overkill while using Tomcat? I mean, is there higher probability that tomcat will act the same on every machine?
After reading the book I mentioned, it seems that the best case scenario would be that every developer should run jenkins and tomcat on their machines, build and deploy only with their changes there (after passing the tests, of course) and then push the changes to the common repository where tests are going to be run again along with the changes of everyone else and the app is going to be built and deployed on production/testing. I can’t think of any case where an app would run on a tomcat instance in one machine and crash on another but then again remember my lack of knowledge.
2