|
Setting Up a Development Environment
One of the services we offer is helping to establish a development environment. Creating a structured development environment is crucial to the success of a project. This subject matter is quite involved. As such, this article cannot go into great detail. The goal is to provide information to get you started. Future articles will attempt to delve deeper into many of the topics found here. Here are some of the benefits to having a structured environment:
You can code in a text editor, but an IDE offers so many nice features such as Syntax Checking, Code Completion, Compile and Building, and so much more. Some of the more popular IDEs include Eclipse, InteliJ, NetBeans, and Oracle JDeveloper Studio. Picking which one to use often comes down to familiarity. There are many articles comparing the IDEs. I invite you to do some research and pick one that you prefer. But. While there really is no wrong or right choice, you should keep in mind that certain organizations will prefer one over another. For instance, with each client I have worked with, Eclipse has been the predominant IDE. As a result, its the IDE I am most comfortable with and will be the one I reference in this article. a. Plugins Most IDEs have the concept of plugins which extend functionality. One of the first things I install is the Spring Tool Suite. Here is a list of other Eclipse plugins that are very useful:
Having consistent code formatting will make it easier for all developers to read and modify code. It also helps with automated code review tools such as Sonar. In Eclipse, code style and formatting can be set in: Windows Preferences --> Java --> Code Style --> Formatter You can also import coding formats if you prefer. Google, for instance, has their coding format publicly available. Best Practices This topic can be quite subjective, but there are some concepts that most would agree on. Design Patterns are descriptions to solutions of common problems in software design. There are general design patterns as described in a book that I think developer should have: Design Patterns: Elements of Reusable Object-Oriented Software There are also patterns for specific frameworks such as Enterprise Integration Patterns and EJB Design Patterns In addition to design patterns, there are many guidelines that should be considered. These are outlined in another must-have book called Effective Java Continuous Integration For a comprehensive explanation, I highly recommend Martin Fowler's article Maintain Code Repository Saving source code to a central repository that is backed up on a regular basis ensures that the code will be saved and stay safe. Source code control tools provide get, update, commit, rollback, and merge functionality to ensure the consistency of the code. Other features such as branching, and tagging allow for easy management of the source code. In addition, most tools maintain history providing the ability to perform analysis. There are two types of source code control tools: traditional and distributed. Traditional source code control tools are based on a local working copy of the source code. Developers make changes to the local working copy and commit them to the central repository. Some of the more common traditional source code control tools are CVS, and Subversion (SVN). Distributed source code control tools operate on the concept of local and remote repositories. This concept is quite powerful as it allows developers to track and commit changes on their own local repository and push to the remote (central) repository when available. The most common tool used for distributed source code control is Git. Remote or central repositories can be private or public. A private repository is one that is maintained internally by a team or organization. A public repository is accessible to everyone. GitHub and BitBucket are good examples of this. Build Automation A build can be as simple as compiling some classes. In this case a simple script can be created, but builds are generally more complex than that. This is where a good build tool comes in handy. Some of the more common ones are Maven, Gradle, and Ant. Each has its pros and cons, so its important to do some research and pick one that is right for you. I have to be honest. I have a love/hate relationship with Maven, but its the one I have encountered the most on client sites and it is quite effective at what it does. It not only creates builds for you, but it manages dependencies and organizes your artifacts. The end goal for a build is to create all of the artifacts necessary to deploy and run a project. It should be all encompassing. A fresh machine should be able to get the source code, run a single build command, and have a working system. Builds should be done regularly on local machines. Ideally before every commit. This ensures that a code change did not break a dependency. In addition, builds should be done on a dedicated machine. These dedicated machines should use a monitoring tool such as Jenkins that can run builds at regular intervals, track their progress, and provide status reports. Self-Testing Builds A build should not just compile code and keep track of dependencies. It should also test the code as it goes. Build tools like Maven are capable of running JUnit test cases and tracking errors and failures. This makes it vital that policies are in place to ensure Developers are creating JUnit test cases for all of their work. Agile development has the concept of Test Driven Development (TDD) where test cases are created first and then the code is created to satisfy those tests. This can be very effective, but it can also be extreme in some cases. As long as test cases are being created, and code coverage is good, then use whatever method is right for your circumstances. In addition to testing, the build should run automated code review tools along with code coverage tools that should fail when certain thresholds are not met. Commit Strategy Source code should be committed as often as possible. This reduces the risk of lost work due to a software or hardware failure, and provides constant feedback to the development team. Commits should be done once a developer has ensured that their code compiles and a local build succeeds. A developer should also ensure that the code is formatted properly and should pass code reviews. These reviews should be reviewed regularly both automated and manually. Streamlined Builds Since builds are done with every commit, its important that they execute as quickly as possible. If builds take too long, developers would be hesitant to perform commits as often as they should. eXtreme Programming (XP) recommends that builds take no more than ten minutes, but every project is different. If builds are taking long, try to defer long running test cases, and look to see if parts of a build can run in parallel. Accurate Deployment Environment Once a build is done, it should be deployed to an environment that matches production. This includes, OS, libraries, firewall and network configurations, and software. Ideally, the hardware should also match along with the amount of data used to test. This ensures that all bottlenecks and performance issues are found ahead of time. Accessible Artifacts When a build is done, all artifacts should be stored centrally and easily accessible by those who need it. Nexus and Artifactory are examples of a central repository. Deployment Automation In addition to automating the build itself, the deployment of the build should also be automated. This will reduce errors and improve the speed and consistency of the deployment. This is especially important when deployments involve multiple environments. Deployments should be scripted to install artifacts, modify configuration files, and provide rollback facilities in case things go wrong. |
Visit our Code Repository for samples and demos.
ARTICLES
All
|