The Client’s Guide to Continuous Integration

Continous Integration
Akash Shakya By Akash Shakya November 17th 2020

Continuous integration is jargon that you, as a client, should understand. So, if you want to talk with your development team more easily, this guide is for you.

What Is Continuous Integration: Our Definition

Continuous integration (CI) is a concept that developers use to guide their collaborative app development process. When performing CI, developers feed their work into a shared database that all developers on the team have access to. In most cases, the export is checked by automation to ensure that code has been transferred successfully.

CI has several driving elements. Those elements are controlled revisions, automated testing, and automated error control.

CI gives developers a huge advantage in agile operation. As each milestone in the development process is reached, the app developer can send the files instantly to their team for testing. 

Then, if an issue is identified, it’s incredibly easy for the development team to identify any errors. They’ll have hundreds of eyes looking at it. 

In short, using CI as a standard for operation allows the dev team you hired to move quickly while maintaining a high level of consistent quality.

The Best Dev Teams Keep It Simple

As with all systems, continuous integration tools only work when everyone is doing their part. A good developer will have a clear and concise way to do their CI so that their employees can work efficiently and effectively.

That being said, it’s also important to remember that continuous integration is only part of the full solution. In fact, it’s hard to even talk about CI without mentioning continuous deployment and continuous delivery. 

So, before this explanation moves forward, we’ll talk through what those terms mean.

Continuous Integration Is Only Part of the Puzzle: An Overview

Now that you’ve been introduced to the very base level of Continuous Integration and it’s principals, it’s time to complicate the definition a little bit more.

We’ll first cover the basics of three principals that make up the software checks and balances that code goes through before release. Our definitions will also include a new explanation of continuous integration that places it in the context of the two elements that it supports. 

Continuous Integration (CI)

As we explained above, continuous integration is the process developers use to feed their work into a shared database. In the CI phase, the imported data is also often checked with automation to identify any errors that may have occurred during the transfer. 

Continuous Deployment (CD)

Continuous deployment happens after any continuous integration practices take place. Using automation, the computer will do several things. Automation will prepare any code to be usable by anyone else as either raw code or as a functioning application.

The automation may also choose to immediately export the imported code to a virtual testing area so long as the imported code passes several predetermined parameters. 

Continuous Delivery (CDD)

Continuous Delivery is often most important after the application leaves initial development and enters into an app store.

CDD keeps your database of code ready to go at any point. Development teams often use CDD to maintain a very fast turnaround time for any updates that need to be made.

Let’s Break These Down Even More

It becomes a lot easier to understand continuous integration, continuous deployment, and continuous delivery when we think about what exactly goes into making each process work.

Continuous Integration

What obstacles does the dev team you’ve hired need to overcome to make CI work well? They will need time to write new code for the automated testing process. They’ll also need an expensive server to store any new code. To make this all happen, constant teamwork and personal responsibility are needed. 

Some of the benefits you’ll see from correctly working a CI process include: 

  • Automation finds bugs before testers or users do
  • Automation can test for integration issues
  • The development team is notified immediately when code is entered incorrectly
  • Your beta testers won’t be subjected to intolerable amounts of in-app bugs

Continuous Deployment

What obstacles does the dev team you’ve hired need to overcome to make CD work well? Their work will need constant internal and external maintenance. Quality control will also need time to validate the continuously integrated code’s usability. Some of the benefits include: 

  • The development process speeds up 
  • Automation allows code that’s complete to integrate automatically
  • Risk is minimized
  • The overall product will be more professional

Continuous Delivery

There are also obstacles to make CDD work well. This step will only work if everything else is already working and the process needs to be automated. If you get everything working correctly, though, some benefits include: 

  • Software releases get sped up by several days
  • Automation will only allow completed updates to pass through its filters
  • Your development team will not need to worry incorrect releases

When to Integrate and When to Deploy

CI and CD are similar but possess key differences. 

The main differences between the two focus on the intent behind both processes. Continuous integration mainly focuses on creating databases that can then be used.

Continuous deployment focuses on using already existing databases to test content. Basically, continuous integration is developer-focused and continuous deployment is tester-focused. A developer may wear both hats at some point but CI and CD still remain separate.

Correct uses of both CI and CD result in an incredibly effective development process.

Continuous Integration to Continuous Deployment

This process takes place almost entirely within the pre-launch process. Because continuous deployment hosts all changes within a virtual location, it is not always fit for full-scale production.  If your developers are working on a completely new ap for you and your customers than the continuous deployment process might be the way to go.

With the continuous deployment process, your development team will be able to test every iteration thoroughly before it ever reaches the final code.

Continuous deployment thrives in a situation that is highly controlled. This means that a closed beta testing group is perfect for a CD workflow. What we gain in testing time, we lose out on speed.

A continuous-integration-to-continuous deployment pipeline cannot be launched as fast as a continuous delivery pipeline. 

Continuous Integration to Continuous Delivery

If the app that you’re hiring the development team to work on is already live, then continuous delivery is your friend.

It’s best to allow your dev team access to the original development team’s code assets sooner rather than later (if possible). This way, your team can begin building out a continuous delivery process. 

Because a new development team is now working on your project, the CI to CDD process will take a little bit of time to ramp up. The development team will need to learn the database, familiarize themselves with the code, and learn the general quirks that the other developer had.

The new development team you’ve hired can then begin running basic updates using a continuous delivery method first. This will allow them to confirm that processes are in place correctly before running any large updates and heavy maintenance. 

This process also has the added benefit of giving the development team the time they need to create their automated continuous integration testing protocols. This slow ramp-up process takes some time, but it will ensure that your application remains stable, fully functional, and bug-free.

The general guidelines that a development company should be following are outlined below for your reference and for your comfort.

  1. A build should have indicated that it was “successful” the developer submits it for continuous delivery. If the asset is broken then it will be returned for changes.
  2. The developer should rebase their workspace to the “successful” configuration after they have a confirmed successful build of code.
  3. The developer should then build and test locally to test for errors before submitting for final review.
  4. After their tests, the developer can submit their code for its final review.
  5. The developer should then run a continuous integration cycle to record the changes they made to the code.
  6. If the build fails again, the developer should retest the build locally.
  7. If the build is successfully continuously integrated the developer can continue on to the next task.

Congratulations! You now have a development team that’s able and ready to meet even the tightest of deadlines.

Next, you can cycle back to a continuous-integration-to-a-continuous-deployment model. Every subsequent major update can be tested safely in a CI to CD workflow. Then the dev team can cycle back to a CI to CDD workflow to finalize the update’s launch.

If you run both systems simultaneously, all of your minor updates will release via a CI to CDD pipeline. Next, your major updates can receive the major testing, that they both deserve and need, in a safe and isolated CI-CD pipeline.   

So What Does Continuous Integration Mean for You?

This article isn’t just about the finer details of CI, it’s about how CI helps you specifically as a client. For you, continuous integration is insurance. So, how does CI help deliver a safer, more reliable product?

CI Reduces Your Risk

Just like employing a test driver to test out your new car design, continuous integration means that your development team has automation continuously testing their work. 

Not only does this deliver reliability, better communication, and an overall higher quality product, it also saves time which cuts down on costs

CI Helps Create Useful Communication

Have you ever gone to a development meeting only to be met with a comment like, “the app is broken and we don’t know why”?

We get it, it’s hard to hear. The huge advantage of continuous integration is that automation catches most errors. This means that instead of hearing “the app is broken and we don’t know why” you’ll hear something closer to “the code broke last night during our import as our automation was checking the intro animation for your characters. We have a developer working to solve that right now.”

CI Helps Us Develop Leanly

With continuous integration, different iterations are released and recorded live. This process resembles the edit history that Google Docs displays.  

Because the import process is automated, CI also automatically generates a record of what was imported. This means that if CI best practices are followed, each iteration will only cover a very small portion of code that can then be reviewed quickly by the entire team and by you. 

These small increments will help us communicate with you to discover how you would like the app to take shape.

CI Gives Us Room to Breathe

By focusing on one thing at a time, continuous integration allows us to think of the bigger picture.

We can ask things like “did us adding the option to go into night mode from the in-app user interface take us in the direction we wanted to go?” or “what’s more important right now, the aesthetic or the functionality?”

This constant review saves both time and money.

CI’s History: Why You Should Trust in the Process

Let’s delve a little bit further into the history of the CI process. The original principles of continuous integration are as follows:

  • Code should be stored in a central location
  • Your build should be automated
  • Your build should test itself for errors
  • The development team should import their work every day
  • All imports should be built
  • All builds by the development team and the automation should be fast
  • The testing environment used by the AI should be that same as the real-world testing environment
  • All code should be easily accessible at any time
  • Every build should be verified by every member of the development team
  • All build deployments should be automated

These principles probably sound familiar, and it’s because we’ve already covered them above (just with more thorough explanations). We’re mentioning them here as an offering of reassurance. 

The above principles have remained mostly unchanged since 1991. At the same time, our ability to implement them has only increased with the new, more advanced, and more reliable technology. 

CI, CD, and CDD Should Make You More Confident

App development, and coded development in general, has gone through major revisions and iterations to create systems that we can feasibly rely on. 

If you would like to learn about our continuous integration practices specifically, then reach out to us. Not only would we love to talk with you about your project, but we’re also happy to put your mind at ease with an explanation of our best practices. 

Akash Shakya By Akash Shakya

Coming from distributed computing background, Akash manages the Sydney operations. He is highly technical yet very business focused and is always driven to create successful business products for our clients.

Read more Articles by this Author