I had the privilege of attending this year’s San Francisco Smashing Conference in early April where I listened to presentations from founders, designers, and front-end developers.
In a previous blog post, I covered the “textbook” definition of continuous integration, along with a handful of tools and practices that fulfill or help to fulfill said definition. These tools and practices include breaking up your app into components (e.g. front-end and back-end, or, for much larger projects, using microservices), utilizing “watch” utilities locally to iteratively run tests, and choosing test-oriented frameworks (e.g. Rails, Django, Grails, etc.). However, I didn’t talk much about any specific continuous integration setup, nor some of the third-party services that go together to make an efficient release process. I also didn’t talk much about how continuous integration fits into the larger cycle of deployment and release management. I aim to cover some of those topics here, and fill in the larger picture of how CI helps to ensure code quality and stability in a software project.
Software Engineering is about more than just writing code. It is a complex process that has a lot of moving parts. Requirements gathering, planning, testing, deployment and source control management are just a few of the pieces to the software engineering puzzle. So how do we manage all this complexity? Software methodologies come to the rescue.
A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.
Continuous Integration at Grio
In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.
As a software consulting firm, Grio strives to provide high quality, high value software to its clients. We embrace an agile software development methodology based on Scrum. This iterative approach provides our clients with flexibility to adapt and change their product over the course of development as discoveries are made while using the software.
This flexibility can prove challenging when providing up front estimates regarding project costs. The problem arises that providing an estimate that is too high may lose you the contract; Estimating too low can result in several outcomes:
In Part 1 and Part 2, we saw the forces of extreme right and extreme left savage two organizations in the name of scrum. One company goose stepped about in Luftwaffe jumpsuits. Another built a gulag for stakeholders who would question its developers-only central planning meetings.
In both cases, malevolent propagandists diverted the team’s purpose, and product progress all but ceased. The right was called wrong. The in progress was called done. The 1 was called 0. User stories were enigmatic and undecipherable.