Delivering award-winning enterprise cloud software to Fortune 500 clients while maintaining an awesome technology stack and team culture is a big challenge! People often ask us how we do it. This blog entry is an attempt to explain that.
Apptio created the ‘Technology Business Management’ (TBM) category. Our products give IT Leaders a common language, coupled with the tools, and data to manage the costs, benefits, and ROI of all the services they provide to their internal customers and stakeholders.
Tools of the Trade
Apptio’s IT Planning products use a multi-tenant SaaS architecture hosted in Amazon Web Services (AWS). It is primarily a J2EE/Jetty, MySQL, and JavaScript stack less than two years old. We currently have multiple scrum teams working on it (and we’re growing quickly).
Internally, IT Planning is structured as a set of several RESTful services, each owning their own data, using Spring for dependency injection. On the JavaScript side, we use a mix of Durandal, JQuery, some GWT, and AngularJS.
Our developers use IntelliJ, primarily on OSX, but there is some Ubuntu as well. We use Gradle for builds, and both Solano and TeamCity for CI/CD. Automated tests use a mix of JUnit, Jasmine, Selenium, and a few other tools. It is quick to compile, deploy, and run all automated tests.
How We Work
Releasing new versions of our software frequently is a priority for us, so we have built our development practices and tooling around that. We currently release our IT Planning products to all customers rougly every other week. Releases are done by our Technical Operations team, using the same auto deploy tools that we use for Dev and QA environments. We use Splunk everywhere (Dev, QA, and Prod), so it is extremely easy to see what the system is doing.
We use a three layer testing approach. Build verification and unit tests are the first layer; integration and functional tests are the second layer; and end-to-end and user experience tests are the final layer. We write tests that are self-contained, clean up after themselves, and fast. Sometimes we have to fall back on UI-driven functional tests executed in a Selenium grid.
Since we use AWS for all of our environments, spinning up a new environment is simple. We encourage developers to branch as often as they want, since our CI/CD system automatically builds, deploys, and tests all branches! Our trunk is called default, and code is only merged in there after it has passed both testing and code review. Default builds and deploys to a full Prod-like environment several times per day. If we get a red build on default, it requires immediate attention. To release to Prod, our QA group merges commits to our Release branch, and deploys from there.
Who We Are
We have relatively large UX design team with all various types of design specialists (visual, interaction, information architecture, research, content). Most user-facing features are designed with a UI spec up front by a UX designer, and reviewed before checking into default.
From a process standpoint, we use Agile Scrum with two week sprints and JIRA/Confluence as our primary tools there. We sit in large team rooms to ensure good collaboration. All code changes require peer review, and automated test coverage has to stay north of 80%. We do Hackathons a couple times per year (with cash prizes for innovations that benefit our customers), and the occasional FixIt as well. We have 3 kegs in the office, and these days one of them often has cider.
We handle periodic code refactoring by prioritizing that work, and allocating some time each sprint (for small things) and each quarter (for bigger things). Since our company has an engineering mindset, conversations about architecture and refactoring are quick, to the point, and easy.
We have a mix of people – junior and senior, full-stack and front-end – and a strong culture of helping each other out. New hires are generally able to commit code on their first day. To protect this culture, we have a rigorous interview process –more than five hours, and coding before or during the interviews. We operate using the combined-engineering model, where we have no dedicated QA people on scrum teams and devs are responsible for writing the majority of automated tests. We do however have a dedicated SDET (test engineering) team for specialized testing.
We always have room for improvement, and we’re constantly evaluating new technologies to add to the stack – but we’re proud to deliver great products – and have fun doing it!
Join Us!
If all this sounds good to you, we’re hiring like crazy, both in our Bellevue, WA, and Louisville, CO, offices! Check out our Careers Page.
