As a current coding bootcamper nearing the end of the program, there is a recurring step in the fullstack process that my cohort and I have used and incorporated throughout our work and studies but none of seem to have a clue what it is. That step is the use of a Continuous Integration system to “check” our code? But check our code for what?
For the first few months of sprints and tests, I just assumed that CI programs like Travis or Github Actions were preset tests made by our instructors to check our code. I can even remember feeling sorry for whatever poor sap had to write those test because that must have been brutal. Come to find out, CI programs aren’t just to check bootcampers horrific code but instead a way for code to be consistent and clean, therefore allowing collaborating coders to be much more efficient.
So, What Is Continuous Integration (CI) ?
Continuous Integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. -Isaac Sacolick (InfoWorld)
Commits
You have most likely been practicing this step of Continuous Integration and did even know you were practicing CI. The benefits of committing early and often are extremely important for new developers. Think of this step as a checkpoint in a difficult video game. When you get to a checkpoint that is right before “the boss” you can rest easy knowing that if you get killed you will just restart at the checkpoint. Now take things a step further, if you were to die over and over and realize you could never beat the boss unless you went further back in the game and found a better weapon or stronger armor, then you would want to go straight to the point where that was possible. By committing often while working on your code you give yourself the best possible chance to easily go back to where you were and try and fix your code from a different angle. CI allows multiple coders the ability to work on different parts of the code at the same time and create a build when anyone makes changes to a repository.
Build
This is a group of source code that is placed in a format that allows it to be executed. If the build is successful, then this means that the incoming changes that are being added to the codebase will not break the code. However, if the build does not pass, the changes in the code will need to be corrected. This is why when you are working with a group it is best practice to do you work on a copy of the project on a different branch as to not affect the main source code. Being able to check code in small increments saves both time and money for companies and coders.
What are Some CI Options?
Although there are many CI options, some of the most popular are: Jenkins, TravisCI, CircleCI, GitLab CI, and GitHub Actions. See below for a simple diagram showing the CI process.
Conclusion
As it turns out, my initial thoughts were, surprisingly, not too far off. The CI set up for us bootcampers was certainly created by our instructors but it was to encourage efficiency instead of just telling us that our code is wrong. The program is running our code in realtime to see if it does, in fact, work. In the real world, teams will discuss and create the build schedule that works best for the team as well as other application considerations. Most teams will require at least one commit a day. This practice will help you to break your code down into bite sizes that you and your fellow coders can understand while holding you accountable at the same time. Hope this helped!
