I want to become more efficient and I want to use ops tools efficiently.
With this in mind, I wanted to learn more about continuous integration, but it seems that there is many different things concerning it.
I m actually working with Jetbrains suits in my work (IntelliJ, WebStorm…), so I wanted to continue using them, and I wanted to use TeamCity which seemed to be a great tool with many plugins for continuous integration.
My problem is that I don't know what are the differences between:
-
building automation (TeamCity is this kind of software):
I know that we can build our application with a remote VCS repository and it's great, but what is the main aim of that ? What kind of information is important while doing this ? In fact, I already know if my software builds or not locally, and my teammates too. So, what is the aim of using it without deploying automation? -
deploying automation (TeamCity doesn't seem to do it easily)
- continuous integration (which seems to be a conjunction of the two above)
- continuous delivery (what is this exactly? why it's different from continuous integration?)
Can you help me to understand a bit more this?
Best Answer
Wikipedia gives pretty good summaries of most of these terms. Here is my take on them:
Build automation is automating how the software is built instead of manually invoking the compiler. This would be accomplished via tools such as e.g. Make or Ant.
Deployment automation is taking your built software and deploying or installing it on a test or production system.
Continuous integration means having an automated process build your software continuously as developers check in code, and run unit tests to ensure the code still works. For example, every 15 to 30 minutes a server might wake up, scan VCS for new check-ins, then update and build the project if any changes were made. In addition to performing compile steps, this is also a great opportunity to run automated unit tests and code quality checks.
Continuous delivery is a combination of all of the previous concepts where the software builds are also deployed to a test system, optionally with tests performed and reports generated.
At the very least, you need to have build automation, i.e. a build script of some sort. That allows you to click one button or issue one command to build your project. The benefit to this is reducing errors from manually running steps. Complex build environments might involve generating code (think DAOs from configs, interface code such as JAXB), compiling code, packaging it up, customizing metadata, etc. With a lot of stuff to do you need a checklist: why not make the checklist be your build script, and use a tool to run it? It reduces errors and provides consistency.
Next up is CI: this is really good to have but not strictly required. It helps identify build problems early. If you have multiple developers checking in code throughout the day and perhaps not syncing up their own workspaces constantly, there is a risk that their changes will interfere with each other. I am referring specifically to static code errors, not version control conflicts. A CI build server will mitigate this risk.
Finally we have the deployment steps. The idea here is to save time and reduce error from manually deploying software. Much like build automation, there are a hundred ways to screw up a software deployment. I have personally stayed late at the office to fix manual deployment problems on many occasions when we need a functioning system for customers coming on-site tomorrow. Automating multiple systems introduces more risk: instead of one system possibly crashing or having weird errors, we now have multiple systems that can go wrong. However, that risk is far lower than somebody missing a step on a checklist or issuing the wrong command and messing up a deployment. If you are lucky you can simply restore a DB backup and start over, if you are unlucky an error might cause the system to function incorrectly. Is it a software defect? Did the technician not set a configuration correctly? This takes time to diagnose, time that you may not have and time that need not be spent if you automate the process.