1. Write your own build scripts
Eclipse and Netbeans do provide some form of a automatic build script when you create the project, but I advise you to do your own since the scripts they automatically generate are usually very complex and if you want to build in automatic static analysis or some code coverage (Findbugs,Cobetura) tool it might be difficult so just go do your own.
Make your script run the unit tests also and put the report on the build server's dashboard.
Make your script run the unit tests also and put the report on the build server's dashboard.
2. Do not check in dependencies
If you project depends on your project teams module, it might be tempting to just get him to pass you the module and you check it in with your project. This is bad, cause when he updates his code, he will need to generate another jar or dll and pass it to you manually.
Better is for you to check out his code and link it through the ide, this ensures a few things, first you just need to do a source code control update and build. You are always kept updated no need for your colleague to keep passing you things and then your build server will run much better.
But then how will your build server when running your build job knows how to get the dependency?
3. Manage your dependencies
Unless your build script for your main project knows how to build all your dependencies first then built itself, but that would make for a complicated script. Why not use a dependency manager like Apache IVY. Everytime your build server builds successfully the dependent libraries, it publishes it to a ivy repository. Then when you main project builds, it gets the dependencies using ivy and builds itself.
Unless your build script for your main project knows how to build all your dependencies first then built itself, but that would make for a complicated script. Why not use a dependency manager like Apache IVY. Everytime your build server builds successfully the dependent libraries, it publishes it to a ivy repository. Then when you main project builds, it gets the dependencies using ivy and builds itself.
4. Make known the status
You want your developers to know the status of the latest build, most CI servers have some sort of RSS, XMPP or you can even link it to lava lamps to get the status. The important thing is to make known that the build is broken and get to fixing it. The place it work uses spark so we use Spark messages to inform the team that a build is successful.
You want your developers to know the status of the latest build, most CI servers have some sort of RSS, XMPP or you can even link it to lava lamps to get the status. The important thing is to make known that the build is broken and get to fixing it. The place it work uses spark so we use Spark messages to inform the team that a build is successful.
5. Deploy automatically
If you are writing a web application, deploy it automatically to your app server so that your PM or others can have easy access to it. You can even run UI tests on it using Selenium.
For tomcat there are ant modules available, for Weblogic you can script them using the WebLogic scripting tool.
This also has the added benefit that you can compile, build and deploy in one step, cutting down lots of time.
If you are writing a web application, deploy it automatically to your app server so that your PM or others can have easy access to it. You can even run UI tests on it using Selenium.
For tomcat there are ant modules available, for Weblogic you can script them using the WebLogic scripting tool.
This also has the added benefit that you can compile, build and deploy in one step, cutting down lots of time.
6. Build installers
For thick client kind of application, automate the building of the installer. You can even build different kinds of installers, i.e Mac, Windows, Linux if there is a need.
No comments:
Post a Comment