We’re back on the topic of continuous integration (CI).
After my last post about the importance of CI and how it relates to Force.com projects, I received some positive feedback, mostly from people asking “That’s great, but how?”. To answer that question, let me first outline the tools we use to implement CI here at Myriad Minds, then explain a little about how they work together.
Our CI implementation uses Atlassian’s JIRA Studio as our preferred platform for project delivery and development. JIRA Studio includes Confluence for documentation and collaboration, Subversion for source control, JIRA for issue management and Bamboo (actually called Elastic Bamboo in a hosted JIRA Studio instance) as the continuous integration (CI) server. Elastic Bamboo utilises Amazon Web Service’s (AWS) Elastic Compute platform (EC2) for compute resources, which allows seamless scalability for any build’s individual resource requirements. This architecture is equally applicable for both client and internal projects.
The following diagram is a high level illustration of our continuous integration architecture. (Click to enlarge)
As the diagram illustrates, code is developed and deployed against a developer-assigned Salesforce Sandbox and subsequently committed to Subversion. Bamboo polls Subversion for changes based on trigger parameters configured when defining the build configuration. Once a build is triggered, Bamboo determines if a valid “elastic agent” is available. If so, it passes the code and build script to the elastic agent to run against the Force.com build Sandbox (as specified in the build script). Upon completion of the build, Bamboo will notify configured recipients of the build’s status. In the event that no elastic agent is available, the build is queued until one is or can be configured to timeout after a given period.
Benefits
- Cloud based configuration and management – can be managed from anywhere the internet can be accessed.
- As the build resource requirements change our infrastructure automatically scales to meet demand.
- No on-premise infrastructure is required, though it’s possible to replace both Subversion and Elastic Bamboo with on-premise alternatives.
- Pay-as-you-go for only the tools you need.
- Security and access is managed in JIRA Studio so developers can collaborate from across the globe – great for development teams spread across disparate locations.
- Tightly integrated with JIRA issue tracking for build reporting and metrics.
Blog
We have been intrigued lately by the notion of using the Cloud for building, but I have a couple questions that I’d be interested in hearing your answers to. In our case, we would likely keep Bamboo and SVN local, but use remote agents.
- How big is your code base? Is it a lot of overhead and time to constantly be checking out (putting extra load on SVN) and transmitting the code over the internet to the build server? Or is there some efficiency there that I’m missing?
- Security – are you at all worried about the code being compromised, either in transit or sitting on Amazon’s servers? Our IT Security department can be, umm how shall I say, strict.
Hi Dave,
The codebase varies across projects but on average say 30 classes / 10 triggers and 40 pages. There is no appreciable overhead in checking in/checking out though it does have to be drummed into developers who are not familiar with the process. Any overhead that is incurred is offset by the peace of mind that you won’t get your work overwritten or lost.
The linkage between the various components in the cloud is via https though you can also configure Amazon for VPN access. We are very happy with our build and see no serious security issues.
I will be posting more blogs so watch this space. Also I will be conducting some webinars in a couple of weeks.
Cheers
Giles