This post was originally published on our blog.

A common problem for many devops teams is a fragmented workflow. Inefficiency can be infuriating.

You know how it goes: individuals on the team tend to work independently. Coding solo, engineers regularly create large segments of code outside of version control. Once a developer is “done,” they add their work into the basecode. Then another team manually runs tests to verify the build.

For years, many teams have found this division of labor annoying and problematic.

When multiple developers separately commit large changes to version control, they create complex bugs, multiply time-intensive fixes, and increase the time it takes to do more manual testing. Everything slows down.

This clogs up your build cycle with tedious debugging, slows down the time to production, and ultimately undercuts your company’s profits.

What is Continuous Integration?

Continuous integration (CI) is a process aimed at cutting out build cycle inefficiencies by allowing developers to compile the team’s code from a shared version control repository. CI also allows you to automate testing so you can set up the system to automatically run unit tests or integration tests for example.

CI automatically monitors the commits that each engineer makes. This streamlines the build and verification of code so that testing is not so high-stakes. It’s recognized as a best practice in the software development community.

CI is run on a shared server that increases visibility, so all the engineers on a project are aware of changes in the base code day in and day out. In addition, you can configure the server to alert developers when they submit failing code so that they can fix any errors they introduce.

Using CI automation allows you to shorten development release cycles and improve product quality. CI essentially lets your team use machines do what they do best, so humans can do what brings more value to a company. And it’s all customizable to your project and your needs.

CI environments can provide various levels of testing automation.

CI/CD servers, including Jenkins, allow your team to set up the tests that you need to run.

There are various levels of testing that you can implement. The most basic test is whether or not the code actually compiles. Code can also be “linted” or checked for style. Your team can write more complex tests to cover other bases as well, including unit, integration, stress, regression testing, etc.

How does Continuous Integration differ from Continuous Delivery?

A CI service compiles and tests a full application (possibly by running the application in an emulator). Continuous delivery also pushes this compiled application to a repository, for example, for alpha testers to use and provide early feedback. CD builds are automatically deployed through to the production environment and can also be used for broader beta testing.

CD is aimed at lean-logistics: automating the process from adding new code through to acceptance testing. CD automates all the steps so that your build is ready to be deployed.

• Continuous delivery: besides building the application and running tests on it, the application is also “delivered,” which often means putting it on a server for someone to perform manual tests on it, or sent by email to a test group of users (eg. a mobile app sent by email).
• For production builds, delivery means deploying the application for the end users.

This allows for faster, smaller deployments of your product which reduce deployment risk. Regular, smaller, leaner deliveries are less risky that huge ones that only occur once or twice a year.

How does Continuous Integration/Delivery help a development team?

A lot of people talk about CI because it is considered a best practice to have all code verified automatically on every commit, regularly run tests, and continuously deploy--for the reasons mentioned above.

The process checks that the contributions from each developer work well together. Detecting these issues early makes it easier and faster to fix the bugs.

As you can probably guess, implementing CI/CD will cause a cultural shift in your team. You will have to become more agile and integrated.

CI was created to allow your team to stop wasting human time trying to manually resolve conflicting segments of new code, trigger builds, or run tests. Instead, it encourages adding small, incremental changes in code so you don’t end up with huge, complex bugs to fix. This speeds up the build cycle, potentially streamlining deployment and production.

And it’s helpful to remember--production is where your business actually makes money.

Also, interestingly, for a multi-developer remote team, CI is extremely helpful to implement because it brings you all together and continuously combines your work so you're all on the same page regardless of geographic location.

Jenkins helps structure the build cycle of a remote team.

How CI helps the Bugfender team:

• Running Jenkins allows us to continuously check that the code compiles and run a set of basic tests that we have programmed to verify the base code after every commit.
• We automatically deploy the merged code to an integration environment, which can be used for manual tests (this bit is called “continuous delivery”).
• We also use it to generate and deploy production builds. Our deployments are complex because we are not updating a single machine: we’re updating a whole cluster of machines. We have to be sure to perform updates in a way that does not disrupt the service. Deployment on such an environment could be prone to errors if done by a human

Intro to Jenkins

Jenkins is an open source implementation of a CI server written in Java that can be used as a self-hosted option automating the build cycle for any project. It works with any programming language and for multiple platforms including Windows, Linux and macOS. According to the Jenkins website:

Jenkins, originally founded in 2006 as "Hudson", is one of the leading automation servers available. Using an extensible, plugin-based architecture developers have created hundreds of plugins to adapt Jenkins to a multitude of build, test, and deployment automation workloads. In 2015, Jenkins surpassed 100,000 known installations making it the most widely deployed automation server.

One of the main benefits of Jenkins is that it is a well-known tool with lots of community support, there are many plugins available (including well-known names like Slack, GitHub, Docker, Build Pipeline + more), and the project is well-maintained by a large community of developers.

There are a lot of conversations going on about CI/CD and the Jenkins project. But even as late as 2017, a surprising number teams don’t utilize or maintain their systems because running a CI environment is costly, either in time or money, often both.

So why even bother with them? Let’s look at that question.

Pros vs. Cons of Jenkins

Jenkins is an old tool with an unfriendly user interface.*

(*The good news is that the Jenkins project just released Blue Ocean, a continuous delivery software aimed at significantly improving the UI. True to form, it is 100% open source.)

As your team considers options for continuous integration, it is helpful to note that Jenkins must be run on a server (cost), so it often needs the attention of someone with system administration skills (time). You can’t just set it up and then expect it to run itself--the system requires frequent updates and maintenance.

Yet, Jenkins is open source and one of the best and most widely used free tools out there for implementing CI/CD for your devops team.

The main barrier to entry for most teams is the initial setup, procrastination, or failed previous attempts to set it up. People tend to know it’s a best practice, but many teams neglect it for more urgent coding work. Perhaps someone on your team tried to implement Jenkins at some point, but did not successfully maintain it. Maybe the wasted effort gave your boss a bad impression about it.

As it is, the reasons people do not implement a CI server are usually very practical.

One main reason: CI systems regularly break. If a setting in the project changes, often it is necessary to readjust the configuration of the CI system. If the CI system is not perceived as highly valuable by the team, they tend to leave it aside, broken, so it stops delivering value.

Yet another reason for not using CI is that you need to write tests. Writing tests is something most developers want to do (i.e. a best practice), but they often don’t find the time to do. Understandably, coding the actual software is usually a higher priority for business than more administrative tasks.

Also, tests break, meaning when the functionality under a test changes, it needs to be updated. If they’re not updated, they stop delivering value, as in the case above. You have to prioritize maintaining the infrastructure yourself or it will not work.

In summary, it takes time to set up and a decent amount of ongoing work to keep it updated. But your team can adapt to streamline the maintenance of the system and tests to increase efficiency.

Of course, there are hosted SaaS alternatives to Jenkins, which could be beneficial if you’re willing to pay a bit extra for someone else to maintain the software. Businesses tend to choose this option when they need a superior UI than what Jenkins offers. But a major benefit of self-hosting is that you have more control over your own data security.

Implementing CI requires a cultural shift, especially from the management. They have to allow time for this "unproductive stuff" to be done, while some of other day to day tasks go on hold.

Still, the brief sacrifice of time translates into long-term benefits for the whole company. With Jenkins, your code is easier to maintain and fewer bugs sneak into production. Your team becomes more integrated. Builds take less time.Your business can ship faster and keep up with the changing needs of your customers.

All of this will require a mindset shift:

CI is not an expense but an investment. And the ROI for implementation can be counted in time saved, errors avoided, and higher quality products delivered more easily to your clients.

Check back in weekly for the next steps!

This post was edited by Sarabeth Flowers Lewis, a freelance writer and co-founder of Lewis Commercial Writing, specializing in SEO and direct response content creation. She currently works remotely with her ginger husband writing for tech, nonprofits, and real estate. See more of her work here.

This post was originally published on our blog.