Introduction to Automation
A common principle in modern development is that you should use a version control system to manage code. This principle is especially important when working with a team of developers. Version control will allow your team to label their changes, merge code with others, and manage multiple codebases intuitively. Continuous integration and Continuous delivery are systems which help automate version control. In these systems each developer’s code is merged daily or at frequent intervals, and is tested against builds. In this way, code is frequently checked to prevent conflicts and errors at an early stage.
Continuous Integration
The ideology of Continuous Integration (CI) is simple: commit early, commit often. In its early stages, CI also involved unit testing to be run on each developer’s local machine. In more modern implementations, build servers are used instead.
Continuous Integration can mean either integrating changes to the main codebase several times daily, or “frequently” depending on the size of the project. For smaller subtasks the code would be integrated several times daily, whereas with larger projects, a more appropriate term might be “frequent integration.” Ideally in Continuous Integration, projects are broken up into tasks that would take no more than a day’s time to complete. This way, code can be integrated at least once per day.
Continuous Delivery
The concept behind Continuous Delivery (CD) is simply the process of continually releasing code into production from your main codebase. Continuous Integration allows different developers within different projects to code changes, automatically test against builds, and integrate them into the codebase. Then, Continuous Delivery is the process of deploying groups of those codebase changes into production together. This is the basis of Agile Development:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
By continuously integrating, this allows developers across the company to strategically group code releases together and continually release features. Before the Agile Development strategy, development teams were faced with massive combinations of code, producing unexpected conflicts and causing what some called “integration hell” while developers integrated code for hours or days at a time for larger, more spread out releases.
Why Use Agile Methods?
Most companies who choose to use Agile methods to deliver code have some major pain points:
- Updating code was nebulous and difficult to manage.
- Developer code was often blocked by other releases, who were potentially waiting on others in a vicious cycle.
- Integrating code for a large release produced blockers and errors.
- Automated testing wasn’t happening until hours or days of work were already invested in bad code.
- End users were experiencing a slow turnaround for issue resolution or new features.
With Agile methodology, releases are constant. Developers “check out” a piece of code from the “codebase” library. They make the needed changes, and “check in” the code to the library again. Before the code is accepted to the library, it’s checked against automated build tests. In this way, developers are receiving a continuous feedback loop. And code is checked right away for errors! Less time is wasted, and more work is done.
Help! There’s so many options!
Yes, there are a lot of tools out there to help automate your workflow. It can be difficult to choose which is right for your team! One of my favorite resources to use when choosing a new company or tool is G2 Crowd. G2 ranks companies as: Niche, Contenders, High Performers, and Leaders. Check out their Continuous Integration findings.
Before choosing the tool you wish to use, be sure to look at how G2 defines these quadrants:
- “Niche” tools are not as widely adopted, or may be very new. They have good reviews so far, but not enough volume of usability ratings to know if they are a valid option for everyone.
- “Contenders” are widely-used, but don’t have great usability ratings.
- “High Performers” don’t have a huge base of users, but of those users, they received a high satisfaction rating.
- Last, “Leaders” both have the largest market share of users, and have highest marks for user satisfaction.
Which tool you ultimately choose will highly depend on your business needs, budget, and team size. Be sure to thoroughly research the available options! G2 also allows you to compare software side-by-side if needed:
How did you choose the software your team uses? What are the benefits and disadvantages? Let me know in the comments, or contact me.
Leave a Reply