The American Psychological Association (APA), the largest scientific and professional organization for psychology in the U.S. publishes the PsycINFO database with 4-million records and more than 90 peer reviewed journals, books, and other publications, starts Beverly Jamison, Sr. Director, IT Architecture, The APA. “We maintain a database of psychological tests and measures and psychotherapy demonstration videos,” says Jamison. The APA publishes member information and other data as well.
Because a broad audience including researchers, practitioners, members of other professions, students, the media, and the public use this data, the APA keeps a precise inventory of the data and its elements, checking it for quality and delivering it in a number of ways including as integrated and multimedia materials in B2B and B2C contexts.
APA Dev and Ops Before & After CI and CD
When Jamison joined the APA, some odd number of perl / shell-based coders like her used the VI editor as their IDE while others of the ColdFusion persuasion used Dreamweaver as their IDE. Developers deployed direct to the live system, at off hours, with the developers and perhaps one QA person testing AFTER the deployment was completed, says Jamison.
The APA uses the Roxy community tool for deployments to MarkLogic to address MarkLogic database instances and configurations, which provides uniformity of the MarkLogic databases, explains Jamison.
The nature and purpose of each team inside Dev and Ops determines the usage of the tools. The work of the MarkLogic team dictates one application usage while the priorities of the identity and integration services team require another. The MarkLogic team deals with data services and data models that are often complex; as such they make a great deal of use of unit testing to ensure that a single change doesn’t lead to broken software throughout, explains Jamison. Identity and integration services uses Jenkins to script their builds and to ensure that each build is current; QA analysts test to ensure that their complex scenarios are reliable, says Jamison. Likewise, the UI team has still another set of priorities and usages.
A Panoramic View of the APA’s New Feature Development Process
First the developer will check out a branch from subversion to a local IDE, make and then test the altered code and run unit and regression tests on existing code, and update unit tests, configuration scripts, and any script changes needed, explains Jamison. The process would then include updating and tagging any JIRA tickets with the appropriate version number for the forthcoming release.
The code would deploy from svn to the given IDE for QA testing, which developers or engineers would run depending on the size and complexity of the system and the current system state with respect to release to the outside world, says Jamison.
“Then the code would deploy to the integrated UAT environment for testing by the business team. Once approved there, we would schedule a production release with the systems engineers handling deployment to live public facing servers,” says Jamison.
How CI & CD Impacts / Empowers This Development Process
CI & CD processes hand the developers and engineers greater freedom in adding new features, relieving their fears of doing extensive damage to existing software releases. A minor feature change or bug fix could see the steps in the above process happen in close succession as CI and CD processes avoid the risks of having to revert the code. “A major new feature or change to a data model would mean taking these steps on separate days with distinct and formal signoffs on each,” says Jamison.
In a word to the wise, Jamison reminds that while tools matter, it is how the teams commit to using them in disciplined CI and CD practices that counts.