If you wish to release your product really fast, you should automate your entire workflow, not just the testing. Having a well designed and smoothly running Continuous Deployment (CD) solution will be the glue between the tools you use, especially between the SCM (Source Control Management) provider/server and the hosting environment you are using. This will also help you to onboard new people and grow your team as they can rely on a fully automated process from day one.

There are many solutions out there. If you only want to get a list of tools, you can look at CloudBees CI, TravisCI, SemaphoreCI, CircleCI, Jenkins, Bamboo, Teamcity or many others. You can also find many articles and discussions out there on the topic with valuable information. There are almost endless opportunities out there. But then the question rises: “How to choose between these?”

Your pick will strongly depend:

• on your requirements,

• on the techstack you have and

• on how you handle your daily workflow.

It usually helps to raise a couple of simple questions online and with your peers first and answer them before picking any solution. This will help you determine which solution would be the best fit for you.

One of the first decisions you have to make is whether you want a hosted Software as a Service (SaaS) solution or a self-hosted solution.

If you prefer a self-hosted solution you need to administer your own server. The SaaS solution doesn’t require this, but it might be more limiting in case you require some edge case features. If you happen to use GitHub, Bitbucket, Heroku, or other cloud services, then it is most likely that you want a SaaS solution as it will fit your already existing workflow.

If data security is very important, then a self-hosted server might be a better choice for you. SaaS solutions generally let you focus more on your core product as you don’t have to spend time on maintaining your infrastructure and keeping all dependencies updated at the cost of some flexibility.

If you have open source projects, you can test them with either solution. Be it a hosted one or a non-hosted one. Both of them have their pros and cons. As mentioned, a hosted (SaaS) solution doesn’t require maintenance of the servers on your side, which leaves more time for you to work / code on your product.

The vast majority of SaaS solutions follow the GitHub model and you can test your open source projects free of charge. Some open source projects do require a lot of control over the build infrastructure though as they might be testing parts of an operating system not accessible in a hosted solution. In this case any of the existing open source CI servers should do a good job, although with added necessary maintenance overhead.

Continuous Integration has many benefits. A good CI setup speeds up your workflow and encourages the team to push every change without being afraid of breaking anything. There are more benefits to it than just working with a better software release process. Continuous Integration brings great business benefits as well.

If you test and deploy code more frequently, it will eventually reduce the risk level of the project you are working on as you can detect bugs and code defects earlier. This means they are easier to fix and you can fix them sooner which makes it cheaper to fix them. This will speed up the feedback mechanism and make your communication much smoother, as mentioned in this article by Intercom’s Darragh Curran: Shipping is your company’s heartbeat.

When you have a CI process in place that is hooked into a Continuous Delivery workflow it’s easy to share your code regularly. This code sharing helps to achieve more visibility and collaboration between team members. Eventually this increases communication speed and efficiency within your organization as everybody is on the same page, always.

As you release code often, the gap between the application in production and the one the developer is working on will be much smaller. Your thinking about how to develop features most probably will change. As every small change will be tested automatically and the whole team can know about these changes you will want to work on small, incremental changes when developing new features. This results in less assumptions as you can build features quicker and test and deploy them automatically for your users to see as soon as possible, thus gaining valuable feedback from them faster.

Having a CI process is not only beneficial for software developers, but for their managers as well. Both parties can gather valuable feedback and gain insights much faster. As you push code more often, you have more data available which you can analyze to check if the product is heading into the right direction. This continuous data flow and the timeline of metrics (like dependency, unit tests, complexity, and code smell) can also help to reflect on the progress of the project more frequently which enables faster technological and business decisions.

• Reduces overhead across the development and deployment process

• Reduces the time and effort for integrations of different code changes

• Enables a quick feedback mechanism on every change

• Allows earlier detection and prevention of defects

• Helps collaboration between team members so recent code is always shared

• Reduces manual testing effort

• Building features more incrementally saves time on the debugging side so you can focus on adding features

• First step into fully automating the whole release process

• Prevents divergence in different branches as they are integrated regularly

• If you have a long running feature you're working on, you can continuously integrate but hold back the release with feature flags.

If you are interested in Continuous Integration tutorials and best practices we suggest you check out some of the engineering blogs mentioned below. You can find very helpful content there.

The CI and CD landscape is changing and shaping rapidly since 2006. Still, it’s worth having a look though at Martin Fowler’s original principles of Continuous Integration. Martin explains the best practice workflow:

1. Maintain a code repository

2. Automate your build

3. Make your build self-testing

4. Daily commits to the baseline by everyone on the team

5. Every commit (to the baseline) should be built

6. Keep your builds fast

7. Clone the production environment and test there

8. Make it easy to get the latest deliverables

9. Everyone on the team can see the results of your latest build

10. Automate build deployment

The industry has been doing pretty well to enable this and software teams largely are able to work with these principles in mind. With the popularity of containers it’s now a lot easier to clone your local and production environment and test there. 

Martin Fowler’s principles are a great starting point to think about best setting up your software development process. Jez Humble and David Farley also point out in their book “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation” that the following list should be a general outline and checklist when you want to submit code.

1. Before submitting changes, check to see if a build is currently in the "Successful" status. If not, you should assist in fixing a build before submitting new code.

2. If the status is currently "Successful", you should rebase your personal workspace to this configuration.

3. Build and test locally to ensure the update doesn't break functionality.

4. If Successful, check in new code.

5. Allow CI to complete with new changes.

6. If build fails, stop and fix on your machine. Return to step 3.

7. If build passes, continue to work on the next item.

You should note that this is only a general outline. You can find many services and solutions which do not follow these exacts steps (like step 2). However, it is good to be aware of these steps. Why?

Because many developers (according to DZone’s research in 2014 up to 41%) believe that they are achieving Continuous Delivery, while in fact less than 10% of them actually do. (The survey was conducted on 500+ IT professionals. A large portion of the respondents were developers (68%) or team managers (14%) with smaller portions of operations, QA, and executive management represented. The majority of respondents were headquartered in the US (36%) or Europe (43%).)

Less than 10% of these people actually work with Continuous Delivery. Let that sink in. This is one of the reasons why it is good to remind us to push ourselves to get closer to real Continuous Delivery. A good checklist definitely helps with setting up the right process and explaining it to your team and, potentially, management.

That’s one of the reasons why DZone, the company behind the research, put together a checklist. In the Continuous Delivery Maturity Checklist you can actually check the practices you currently perform to see how mature you are in each area of Continuous Delivery. The higher you score on the test, the closer you are to achieving CD Maturity. The checklist is not only good to follow when you code, but it can also help you identify weaknesses and areas to improve in your company’s CD process. The main areas of the CD process include:

• Source Control

• Build Process

• Testing & Q&A

• Deployment

• Visibility

You can download their checklist here.

An earlier version of this process which you might want to have a look at was introduced by Chris Shayan, when he wrote about the Continuous Delivery maturity matrix below.