In order to meet the many challenges of producing loads of different app/server projects large and small in extremely rapid succession, Appster collaborates on, automates, and dashboards everything it can. “Unlike traditional product companies (i.e. one product with lots of developers) or corporate IT shops (i.e. silos of products and services that rarely change), Appster has to handle a wide spectrum of software projects across a myriad of industries and vastly different client profiles,” says Martin Halford, CTO, Appster. Many of the projects Appster works on are mobile apps.
To do this, the DevOps tools and processes must tackle each new and unique development project in a continuous project stream with the same fervor that any large development project requires. “Our DevOps focuses on automating testing, builds, and deployments for highly custom, highly complex app/server software development projects,” says Halford.
The tools that help Appster to accomplish this include the XCode IDE, the Eclipse IDE, Atlassian’s BitBucket, SourceTree (for source control), and Jira (for Agile project and issue tracking), Jenkins for build automation, Amazon Web Services, and Klipfolio for dash-boarding, lists Halford. “And due to the short turn time and short duration of app/server projects—between 6 to 16 weeks—Appster does not at present practice Continuous Integration,” says Halford.
Appster has three main objectives: to deploy only from BitBucket, to protect the non-development servers from the developers, and to display the build statuses via dashboard to all. Deploying only from BitBucket holds the source code repository accountable as the “single source of truth”, says Halford. In order to protect the non-development servers, developers do not have root level access to the testing, staging, or production servers, only to the development server in this four server stack, Halford explains. Further, the QA Team has access to the development and test servers as well as limited access to the staging server, but no access to the production server. Only the Dev Ops Team / Linux Admins have access to the production server; they also have responsibility for the maintenance and administration of the entire server stack, Halford says.
App Dev At Appster Prior To DevOps
Prior to moving to DevOps approaches, Appster developed apps using manual steps and documented processes that were prone to human error, says Halford. “The process was also prone to human shortcuts and attempts to hot fix builds by circumventing source control and documented protocols such as those that demanded that no one make direct updates to the production server,” Halford says. These issues were not immediately uncovered.
A Typical Trip Through Today’s Appster Development Sprint
CTO Martin Halford shared his take on a round trip through Appster’s development process today. Appster will first generate development servers from saved generic Linux server images, which the Dev Ops Admins will also secure. Servers will ultimately include development, testing, staging, and production servers (or DEV, TST, STG, PROD). Appster will then generate source repositories in BitBucket, and Jira Projects that it will link to BitBucket. Appster will also create a product backlog using an Agile Scrum Software Methodology.
According to Halford, the development team will begin to develop software using Sprints, and each Sprint will follow this process:
A. The developers will check out their code and associate tasks with User Stories and / or Bugs in Jira.
B. They check code in as Changesets that are attached to tasks, which are in turn attached to User Stories or Bugs.
C. Developers automate and deploy builds as needed to the development server.
D. At the completion of a Sprint, the QA Manager selects completed tasks (User Stories/Bug Fixes) for deployment to the test server.
E. BuildMaster initiates the build, which pulls Changesets from the source repository, generates the build, and deploys it to the target server for testing.
F. After a successful Smoke Test, the QA team performs more involved tests to verify the build.
G. BuildMaster follows a similar process to deploy the build to the staging server for User Acceptance Testing.
H. The next Sprint begins and the cycle repeats itself.
Concluding Thoughts
“DevOps can heighten the effectiveness of mobile development by forcing and enforcing discipline on all parties, preventing human error, speeding QA testing cycles, effectively stopping defects, and highlighting inefficiencies in the existing development process such as could be alleviated through additional developer training and mentoring,” says Halford. Further, having a dashboard that is visible to all parties providing transparency into server issues so that Dev Ops Admins can respond immediately during build or production is critical to the DevOps process.
