Browsing All posts tagged under »continuous integration«

My Return Visit to the Montgomery County Java User’s Group

February 17, 2012


On Wednesday night, I returned to the Montgomery County Java User’s Group (MCJUG) to give a follow-up to last year’s Continuous Delivery talk.  This week, I focused on the tools and techniques that a developer, team and organization can use to migrate to Continuous Delivery.  The subject areas which I touch on are: Version Control Build Automation […]

Gotcha when changing TeamCity’s default port

November 17, 2011


I ran into an issue today where I changed my TeamCity default port (from 8080) and found that my build agents were suddenly disconnected.  After some fiddling around, I discovered that I needed to manually change each Build Agent’s configuration to point to the new master server port. To make this change, open up the […]

GitFlow and Continuous Integration

September 14, 2011


I came across an interesting blog post by James Carr discussing his workflow when building Java applications.  In general, I think that the stack and process he mentions is top notch.  I love Gradle, Jenkins, Artifactory and Git/GitHub.  I have been playing with or using in production all of these tools and they are amazing. […]

Continuous Delivery Presentation at the MC Java User’s Group

June 17, 2011


This past Wednesday night, I gave a presentation to the Montgomery Country Java User’s Group on Continuous Delivery.  I was lucky enough to be given the opportunity to speak to a  smart and attentive audience, and I look forward to going back and giving another presentation in the future.  I want to thank Victor Semenov, who organizes the […]

Continuous Integration Interview with SD Times

November 3, 2010


I was recently interviewed for the SD Times for an article on Continuous Integration. The focus of the article is on using Continuous Integration on non-Agile projects.

Build Once, Deploy Many

September 9, 2010


I have encountered more than one development team who takes the approach of building their application from source for every environment they plan on deploying to. While this approach works (and depending on the technology, may be necessary), it introduces numerous opportunities for errors and makes debugging a failed deployment increasingly difficult. By migrating to a Build Once, Deploy Many approach, your team can simplify their deployment process, by making it repeatable and easier to debug.