The Jay Nine Inc Development Pipeline Explained

Jay Nine, Incorporated utilizes a development process heavily based on DevOps and “Continuous Integration” principles. We’ve found that an easy way to boost the productivity and quality of our business app development is by utilizing continuous integration.

Continuous integration provides safeguards for teams—even across different time zones—to create large and complex systems with a drastically higher level of confidence and control. The apps those teams build and deploy are more efficient, providing rapid feedback on any problems we may introduce with the changes we commit. says “The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.”

In essence, we want a fast flow of left-to-right from development to IT operations to the end user (customer). To maximize this flow, we need to bring small pieces of a project to production faster, using more efficient intervals of work.

For the sake of explanation, I’m referring to everything as a “task.” A task can be as small as changing the logo on a website, or as large as creating a new app from scratch.

The Deployment Pipeline

The pipeline for taking a task from production to development should be:

  1. Analyze the Requirements
    1. Seek perfect clarity on what the task at hand is
    2. Take a minute and make sure that this is a task that needs to be done properly in the first place. There is nothing worse than doing well that which not be done at all.
    3. Confirm all developers fully understand the requirements
    4. Create the test case we will run to test the task
  2. Design/Programming
    1. Task is developed and worked on
    2. Task is documented
    3. The process for testing this task is effectively passed down to QA
  3. Implementation
    1. Task is moved to the testing environment
  4. Testing/Verification
    1. QA should review the document of tests created in step 1 or step 2
    2. QA should test the task
    3. QA needs to test the task to try and break it (as a user will) not to try and make it “pass”
    4. If the test passes, it can be moved into production. QA needs to use a video to document testing the test, one that can be sent to pertinent parties to confirm the success or failure of the task
    5. If the test fails, it should go back to step 1, and repeat

The Pipeline Dissected

The first step is to “Analyze the Requirements.

We need to be sure that this is a task that needs to be done (not just some fleeting idea or “nice-to-have” that is distracting from more important tasks). The developers and builders understand with perfect clarity what the final product looks like. If they don’t, they need to.

For example, if we’re switching out the logo on a website, the test would be:  “Logo should look proper on all major devices (including phones) with no pixelation and without impacting the page load negatively.”

The philosophy dictates that the teamn needs to develop the test, first. This is a process known test-driven development. First, the developer writes a failing test, and then completes the task until the test passes. If the test doesn’t pass, the developer knows the task isn’t ready yet

The “Design/Programming” step is a fairly straightforward second step. The programmer develops the code for this task until the test written in the prior version passes. The biggest failure point here is when a junior level developer goes unchecked in creating the code for the task. Remember, it’s fundamental the task is thought of in the ecosystem of the application as a whole. In the example of updating the logo on a website, if the programmer isn’t careful they can break the elements around the logo (often either the website tabs/navigation or the phone number/contact information). The programmer needs to ensure this is done to be scalable and not break important other functionality.

Next is the “Implementation” step, where the program moves to a “staging” version of the app. This environment is a replica of the live server.

The last step is “Testing/Verification.” In this stage, a user or QA person uses the task description provided by the business, and make sure it works as intended. The goal here is not to ensure the task works.

Instead, the goal is to try and break the program.

If a QA person isn’t ruthlessly trying to break the implemented task, we can be sure the users will. Completion of this task should include an easy demo via video (which is better when working across time zones or busy schedules) and any necessary documentation needed to log a completed task.

Why is This Pipeline Important?

Fundamentally, this process must flow from left to right, and the team may find themselves spending more time than might be considered necessary on “Analyzing the Requirements.”

The environment these tasks are developed, tested, and deployed in is critical. All developers must be working in harmony to ensure full understanding of a task before it begins. There is no room for lazily investigating a task, nor room for cowboy programmers and working in silos.

All members of the team should be thinking about the project as a whole, not just some little part of the code. Identical to an assembly line, having to go back and fix a step doesn’t speed things up. It slows down production and deeply impacts the company as a whole. Here is a why, in the first stages of the process, developing tests and focusing on the end goal will minimize this downtime.

The business leaders and project managers need to question the validity of a task constantly. The leaders need to ensure the tasks are being done to benefit the end user, the final consumer of the program. There is nothing worse than doing well, that which need not be done at all.

Repetition and practice are the key steps to mastery. When we integrate this process, we require all developers to do this on even the most simple of tasks. Otherwise, it will fail in production. If the developers, QA teams, operation teams, and business executives aren’t working closely, it will exponentially increase the number of issues in the production software.

If Apple has taught users one thing, it’s that software should just work. There shouldn’t be a lot of unnecessary troubleshooting or education, a user wants the software to perform the task as they see it. The process outlined in this article helps ensure that we can deploy many tasks into production using continuous deployment principles while giving users exactly what they want (increasing the profitability of the software).