Years ago my company, Goomzee, updated our internal development tools to leverage “the cloud” for best-of-breed solutions. Just like other systems, we assess and update them from time to time and wherever possible, eliminate the need to maintain it in house (specialization of labor). After evaluating various agile/scrum tools, we decided it was possible to manage a modern SDLC by just using Github with a little prior organization.
Over time we moved from managing our own email (squirrelmail), to Exchange, to hosted Exchange (themessagecenter/SaasHost), to Google Apps for Business.
Over time we moved from target, prospect, customer lists in Excel, then tried out Salesforce, decided on SugarCRM (better built-in email campaign management), and later switched to Highrise.
Originally we used email with folders and flags, then case management in CRM, but settled on Zendesk. Modern SaaS tools these days integrate nicely via APIs and Plugins, so we try to use the right tool for the right job.
We go through the same process from time to time with our DevOps tools, and even server operating systems. We switched from CentOS Linux to Ubuntu Linux, Subversion to Git source control, Trac to Github ticketing/SCM, and Jenkins to Drone.IO continuous integration. We also introduced Ansible after checking out Chef and Puppet for IT Orchestration.
In the late 90’s and early 2000’s the popular practice was waterfall and Gantt-style PM tools like Microsoft Project, then extreme (XP) or pair programming and IBM’s Rational suite, then agile/scrum. Regardless of methodology, however, the SDLC rarely changes and tools evolve over time. My goal was to reduce the systems we use wherever possible and automate anything we could.
I’m a firm believer in lightweight project management tools and getting the business out of the way of the engineering process as much as possible. I really liked Trac, which was a lightweight SCM tool for SVN, and we had our processes and workflows really dialed in. When changing to Github, we struggled at first to figure the best way to leverage that tool without needing yet another PM system. By using a combination of Issues, Milestones, and Labels we were able to manage our process efficiently.
Releases / Backlog
For continuous integration, and agile, the fallacy of most is thinking that releases no longer exist and waterfall is dead. In reality, you still need scope of a minimum viable product (MVP), requirements, enhancements, defects and milestones and overall project plan.
To accommodate “agile” concept of backlog, we simply keep an always-open milestone titled “To Be Prioritized” with a due date far in the future. For initial product releases, we start with a 0.1.0 milestone and thereafter, we bucket ongoing maintenance tickets in milestone 1.0. For major releases we’ll add another milestone but these can be a year at a time.
User Stories / Sprints
Product management starts with user stories for each “requirement” and “enhancement” as it’s own issue (ticket). It is labeled accordingly to track the lifecycle from requirement, development, testing, and release. Defects “bug” are managed the same way.
For “sprints” we simply move an agreed group of tickets in “To Be Prioritized” milestone to the current open release milestone and then leverage Labels. The dev and QA team still has daily “stand ups” and a continual reprioritization as needed.
Continuous Development / Integration
Github integrates nicely with other tools using “webhooks”, which are simply HTTP requests to a defined URL when some defined event occurs. When a source code commit is performed for a specific branch (e.g. ‘dev’, ‘master’), Github sends notice to our selected continuous integration (CI) tool, Drone.IO. Other popular tools include Travis, CircleCI, and even Jenkins.
In our ongoing quest to automate everything, we decided to skill up our Tier 2 support staff to write automated tests for confirmed defects, enhancements, and new requirements. It’s a work in progress, but this can better leverage experienced engineers’ time to focus on delivery and improve test coverage.
Support team members can write the user story in the Github issue, check out latest code, write the automated tests to represent the requirements. In issue comments, you can reference tickets in Zendesk. In code commits you can reference issue number, so there is automatic requirement traceability.
Once the code is committed and pushed to Github, the webhook triggers the CI server (in our case Drone.IO) to spin up a virtual server on Amazon, check out latest source for that branch, and run automated tests which should fail and thus not push latest code to servers. Engineers are notified on fail, and support staff reassigns the Github issue to an engineer.
The assigned engineer then writes the implementation code to get test to pass. Once a test passes and code is committed and pushed to Github, the webhook triggers CI to push latest code to the server. This process can occur many times per day and supports continuous development (CD).
Even though we use Github’s “milestones” they remain open and code is pushed to production constantly, and our process support TDD, CI, CD objectives. By using Github and a CI server that integrates with it via webhooks (or service hooks), we are able to leverage “agile” methodologies but keep the required systems as minimal as possible.
To monitor progress along the way, we use “labels” and once commits are pushed to the master branch, Github will automatically close the issues (provided you reference the issue # in your commit message). The “milestone” view gives us a quick glance on outstanding issues for the current sprint. We can also track the “To Be Prioritized” milestone and if growing too much, we can increase engineering resources to help clear the backlog.
Github, with some configuration and proven processes, can more than accommodate running the entire software development lifecycle (SDLC).