Confidently ship code using Continuous Integration (CI) and Continuous Delivery (CD)
Posted May 1, 2019 | 10 min. (1924 words)We all want to ship code on a daily basis.
As developers, we want the faster feedback cycle that comes with continuous delivery, and we know it’s better for our team and product in the long run. So why do so many development teams still have such long release cycles?
While long release cycles are tried and true and can be seen as more stable, teams sacrifice much more than faster feedback cycles.
Break the habit of slow releases
When a company is in its infancy, it needs to establish many processes, one of them being the release cycle that it wishes to implement. Although this process can mature over time and can be improved upon, more often than not, it usually remains the same as new updates are released. Years can go by, and release cycles stay the same.
Historically longer release cycles have been the status quo—teams that follow waterfall methodology will be familiar with this. But, with the rise of Agile practices, more software teams are breaking away from longer cycles and replacing them with shorter, incremental alternatives.
Longer release cycles do have their strengths; they are well-tested, predictable, and stable. But these benefits come at a cost. With longer release cycles, teams are able to release large, press-worthy updates that can leave big impressions on customers, potential customers and competitors. However, many startups are able to out-gun their larger competitors by adopting shorter release cycles, which enables them to move rapidly, react to change, and focus on innovation.
By choosing not to adapt and leaving your longer release cycles to stagnate, you are giving your competition the opportunity to get the upper hand.
It’s time to break the habit using continuous delivery.
Benefits of continuous delivery
Continuous delivery comes with many benefits for all areas of your organization; as a software developer I have listed my top five that make the biggest impact on a daily basis below:
1. Shorter issue resolution times
When writing software, there’s always a risk that the new feature or piece of functionality you’ve created will introduce bugs to your application or website. Shorter release cycles, make it much easier for you to react and fix problems when they arise.
2. Focus on innovation
Shorter release cycles also enable you to release new features to customers as soon as they are ready. Depending on your method of delivery, this means that you can go from the conceptual stage of an idea to delivery within a matter of weeks.
3. Market responsiveness
Market conditions change constantly. Whether you’ve just discovered a new product is losing money, or that more customers are visiting your site from smartphones than laptops, it’s much easier to make a quick change if you are already practicing continuous delivery.
4. Faster feedback
Releasing new features early and often means you get more frequent feedback, giving you the ability to iterate and learn from your customers. This ensures you’re prioritizing the right kind of work that will make your customers happy.
5. Developer QOL
Continuous delivery means the responsibility of deployment is spread widely around the organization. Releasing smaller, incremental deployments to your software helps alleviate the stress that can come from one or two people having to deploy a massive piece of work.
Best of all, a successful release becomes a shared success amongst stakeholders—one you can all celebrate together.
Here at Raygun, we celebrated the release of our new Application Performance Monitoring tool with a Pizza party! It was a great opportunity to congratulate everyone involved in the project and, like, who doesn’t love Pizza?! 🍕
Raygun’s CI/CD workflow
Creating a CI/CD pipeline requires the development, test, and operations teams to work together to create a cohesive release process—and the key is automation.
At Raygun, we use a range of different tools and processes to ensure a smooth deployment and minimize impact while also being able to move rapidly and deploy often.
By using this process, we have been able to make over 365 releases in the past year to a range of different areas of our product. That’s one deployment every day! The below graphic shows our workflow.
Where Raygun’s process starts
Issue and project tracking
Firstly, before we can start deploying anything, we need to know what pieces of work we are going to be completing. Having an issue tracking tool makes it easy to create, manage and prioritize items of work to give you a complete overview of the current roadmap and what’s coming up.
At Raygun we use Atlassian’s Jira tool—this provides the level of granularity that we require and makes splitting up pieces of work a breeze.
There are other great solutions out there, so it’s worth checking them out for yourself and choosing one that best suits your needs.
Possible alternatives (there are many others):
Development
Once we know what we are going to be working on, we then need an appropriate IDE for the work to be completed. Depending on what languages & frameworks your project uses the requirements needed from the IDE can differ.
The choice of IDE is down to developer preference, but I choose to use Rider when working in-app and VS Code when working on other areas of our product.
Version control
When working in a team, having good source control is a must. This enables teams to view historical changes made to the codebase, identifies who made those changes and enables developers the ability to work in parallel on the same files.
Git has become the major player in the version control space. As for hosting, there are many version control hosting solutions out there, but we use GitHub.
When we’re ready for our work to be merged and deployed we push up our code to GitHub and create a pull request. This then gets peer reviewed and once approved, merged.
Possible alternatives:
Build management
Build management is the first part of the CI/CD pipeline where we can introduce automation. In this step of the process, we can set up triggers to initiate a build when someone pushes code up to the GitHub repository. You can customize your build script to execute the required tasks to build your application and run a variety of integration tests on the updated build.
Once the build has completed and all the tests have finished running, we will now have a passed or failed build. If desired you can then have it automatically post into a notification service like Slack.
Running this every time someone pushes code brings two main benefits:
- It’s easy to know if you have unintentionally impacted another part of the application causing unexpected or broken behavior.
- You always have a build ready for deployment to either test or release without needing to do anything.
We use TeamCity as our build management server and write our tests using NUnit and Jest.
Possible alternatives to TeamCity:
Alternatives for testing tools depends on your technology stack and requirements.
Deployment
Gone are the days of manual deployment (well, to a degree). Automating your deployment process can severely decrease the complexity of making a release and ensures that certain processes are followed precisely. By using a tool such as Octopus Deploy, we are able to create releases at the click of a button.
We are able to log information around each release, view the dashboard of what releases have been deployed to which environments and historical deployment information for each project you have set up.
The best part is—if you needed to roll back to a previous stable release for whatever reason it’s as simple as choosing one of the releases from the history and hitting deploy.
It’s not all machines, we want humans involved too.
We intentionally remove some of the automation from this part of the process so that we can mitigate some of the risks that come with the continuous delivery model.
We’ve automated everything up to the point of hitting the deploy button, this is because we want a human to be in control of this. By requiring the developer responsible for the changes to deploy out their work brings many benefits to the deployment process.
Because they are more involved in the process, they get to see their changes go live and get to be the first one to test it out in beta or production environments.
Possible alternatives to Octopus:
Alerts
After deployment, it’s often hard to gain visibility on any issues your users come across. Using an error monitoring tool such as Raygun you can pick up on these problems in real-time and fix them before they impact any further users.
Implementing this with our Slack integration you can be assured that bad deployments are caught early and resolved.
We have many other great integrations for a variety of different tools that I will cover in the next section.
Resolution
Now that the update has been shipped we can now close off the work item by going back into our issue management tool and updating the status to resolved.
It’s worth notifying stakeholders that this has been completed before looking at the backlog and starting on the next piece of work.
Success
Now that the work has been released it’s worth celebrating a little!
Announcing new features to customers via the what’s new section or product newsletters is a great place to start. You can then move on to doing things like NPS surveys and talking to customers through messaging tools such as Intercom.
Internal celebrations are also a great way to educate your colleagues about new features in your product. Here at Raygun, every week we get the time to demo things we have released to the rest of the team and congratulate one another.
Feedback
Feedback helps to close the loop on your CI/CD pipeline, and although you might not be involved with the customer feedback side, your product team will be listening and informing the product direction. While collecting feedback using tools like Intercom and AskNicely for NPS—we also use our knowledge that only 1% of customers will report issues, which is why we monitor everything for problems using crash reporting.
Integrations
If you’re looking at setting up your CD/CI pipeline, and you’re interested in adding an error tracking tool like Raygun, we have a range of integrations for a variety of different tools so Raygun can fit seamlessly into most tool stacks.
Our most popular integrations include:
Team collaboration
- Slack
- Campfire
- Flowdock
For sending error notification messages to notify team members
Version control
- GitHub
- Bitbucket
- GitLab
Connect Raygun error groups to issues, resolve Raygun errors from closing issues and view lines of code that caused certain errors to occur inside Raygun.
Issue and project tracking
- Jira
- Azure DevOps
- Trello
- Zendesk
- FogBugz
- Lighthouse
- Assembla
- YouTrack
Create new issues from inside Raygun and link errors groups to work items inside your issue tracking tool.
Service bus
- Azure service bus
- Amazon SQS
Configure your own custom service pipeline with Raygun integration.
Incident response
- PagerDuty
- VictorOps
On-call support for Raygun error rate monitoring.
But that’s not all, you can check our full list of integrations here.
Wrap up
Continuous integration and continuous deployment is modern development practice, and it’s worth the effort to implement. Raygun not only helps strengthen the CI/CD process, it also provides your team with visibility into software errors anywhere in the SDLC, including production. See how it works here.
@olwiba | Ollie.Bannister.me
