Build automation vs deploy automation vs continuous integration

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?

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.

Continuous Integration is the practice of merging all developers changes into a shared mainline several times a day. This practice is now so ubiquitous that it may not seem that significant, however traditionally teams would work on software for weeks or even months in isolation. The result was “Integration Hell” when separate streams of work were merged together. Continuous Integration is normally used with automated builds of the shared mainline to find problems early, but its more about frequent commits and developer workflow than it is about DevOps.
Automated builds are valuable for picking up issues that might cause the build to pass locally, but fail on the build server (e.g. you forgot to check in a file, the dependencies on the build server don’t match). Having the build server detect these problems means you can fix them before your teammates do.
Continuous Delivery involves continuously deploying, running and testing your software. While automated builds ensure your software actually builds (and the unit tests pass), it doesn’t mean that your deployment scripts still work or that your software actually runs end-to-end. The goal of Continuous Delivery is to have a series of checks that ensures the mainline stays in a state which is suitable for deployment to production.
Continuous Deployment is the next logical step – automatically deploying every commit that successfully passes through the continuous delivery pipeline. There are several benefits to this practice, but for me, the main idea here is that small, frequent commits are less risky.

I recommend reading this book for more information:

Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation

Teamcity like many of the build tools is just a central app that allows you to run many different tasks. This includes performing builds like CI builds, full release builds and it allows you to perform deploys. If you are using teamcity to call ant or nant to run msbuild on a solution file, you can also call nant scripts that will perform deploys. It may require a little scripting but its not to difficult.

We use teamcity and bamboo for full CI’s, Database CI’s and deploys to the INTegration environment. We then use teamcity for full release builds and creating db migration scripts automatically. These are checked into SVN via teamcity jobs calling out to nant scripts. For the deploys, you guessed it, we use teamcity to call out to nant to perform deploy tasks. This works well since the teamcity agent talks to the teamcity server and the agent can exist on one of the servers in a DMZ location which helps with moving the code beyond firewalls, etc. So teamcity or bamboo is all you need to handle the entire scenario.

Filed under: softwareengineering - @ 15:29

Thẻ: continuous-delivery, continuous-integration

Thiết kế website giá rẻ

Danh mục

Build automation vs deploy automation vs continuous integration