Hey and welcome to my short gist explaining the basics of Continous Builds and Continuous Integration and how they fit into the Software Development Lifecycle!
This section aims to give users a brief introduction to the Software Development Life Cycle (SDLC) and explain Continuous Integration's placement within this Life Cycle.
CI really concerns the last 3 phases of the cycle outlined below. The idea is that, when we add something to our codebase, it could break our codebase :(. In order to prevent this, we execute automated tests and rebuild our system whenever new code is added to the codebase. These tests and builds should check whether our System is still working as a whole. If it isn't we want to alert the development team so they know to fix something and not merge these changes into another branch !!!.
- Requirements Analysis - This phase consists of lots and lots of analysis. We want to talk about what the objectives of our (clients') project is and suggest alternative solutions, as well as conduct a cost-benefit analysis of implementing our changes. We then go on to define, explicity, requirements for our system based on what our clients and users require and on ensuring that we maintain the great parts of our system and reduce the "not-so-great" parts.
- Design - This is where we plan out what we are going to add to our Software (System). We'll sketch out UI Mockups here, generate sequence diagrams, statecharts, write pseudocode etc. Keyword here is plan.
- Implementation (Development) - This is where we code! :) We make up a prototype of our system here and write Unit Tests for our functions as well as integrate our changes into the System as a whole!
- Testing - We need to make sure that our Software (System) is robust, so we test it here! These tests can be automated tests as well as user tests!
- Evolution - We need to maintain our system and add additional hotfixes / bugfixes to ensure that our Software (System) continues to work well and be up to date within the context of our deployment!
The name is literally only two words:
Continous - CI takes place regularly, its something that should happen when people are working on code, not just monthly, weekly or even nightly.
Integration - The idea of CI is that we want to integrate all our developers' changes and make sure that they all work well together. This should be done in a way that we can rigorously verify that these changes don't break anything - hence the tests and builds.
Travis is a nice tool to introduce you to the concept of Continuous Integration. Its now available as an app on the GitHub marketplace which means that it is able to integrate with your GitHub repository and display build statuses on your commits and pull requests. Using travis is as simple as adding it to your account and adding a single file to your repository.
This magic file is what configures your build for you. Let's consider a simple python script that you want to 'build' (in reality this is just running tests / running the script because Python is an interpretted language and not a compiled one). An example travis.yaml file to configure this would go something like:
language: python # What language are we using?
sudo: required # Do we need sudo somewhere in our scripts? Lets just say yes...
dist: trusty # Which environment (OS etc.) are we using. See travis site for the different options.
python:
- "3.6" # Which python version do we want to run?
before_install:
- ls # Lets list all our files before starting our installation process - this isn't that helpful but,
# lets do it because we can.
install:
- pip install -r requirements.txt # Lets install our requirements using pip from our requirements.txt file
script:
- python Main.py # See if main script runs, if it fails the build fails, if it runs it succeeds (assuming the script ends!!)
notifications:
email: false # Please dont email us when a build passes. Thanks.So what this tells Travis to do is, everytime I commit or create a pull-request, run the build / scripts I defined above. With a Gradle project you could tell it to build the project and run unit tests, with a C-project you could attempt to compile using your makefile etc.
If you added Travis as an app, you'll see that, after adding your travis.yaml file, every time you push to your repository, your commits will undergo status checks. This looks a little like this:
And if your build fails 😓 :
TODO