Skip to main content
uk

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page

BANKING
Banking like a start-up.
MEDIA & BROADCASTING
Capture your audience
EDUCATION
Do your systems pass the grade?
MINING & RESOURCES
Innovate with confidence.
GAMING & WAGERING
Game day performance.
 

Optimising Your Continuous Delivery Toolchain

By Planit Testing

INSIGHTS // Articles

1 Nov 2018

#JIRA|#ProjectManagement|#Tools

INSIGHTS // Articles

#JIRA|#ProjectManagement|#Tools

By Planit Testing

1 Nov 2018

Building quality software starts with standards and well-defined processes. At our recent “Evolving Your Delivery to Meet Customer Demands” event in Sydney, Atlassian Team Lead, Tim Pettersen, discussed how an integrated continuous delivery toolchain can help with shipping high quality software at speed.

Optimising Your Continuous Delivery Toolchain

Continuous Integration (CI) is when all of the engineers in a team to combine their code together and run an automated test suite against it. The idea behind this methodology is to get feedback fast whenever you introduce regression and it breaks something in an application that previously worked.

Continuous Delivery (CD) is an extension on top of CI that allows developers to release their software to your users regularly. This approach uses a broader feedback loop where you get feedback from real people that are using your applications in a continuous manner.

Tim said the faster feedback loop enables developers to release more frequently. It also enables businesses behind the software to react quicker to changes in the market and validate the decisions that they make in the product are actually what customers want.

Since CD consists of releasing more frequently, Tim said each release tends to be smaller and less likely to contain a defect that is going to affect the production environment. It also means if something does go wrong, there’s a much smaller area to look at when it comes to identifying what the problem was and then fix it quickly.

Another benefit of releasing more frequently is that it tends to make teams happier. This is because team burnout is reduced because of the streamlined release process.

New way of working

Traditional projects that didn’t use CD would work towards a major release, which could take days or weeks. What would happen is an engineer would be nominated as a release manager, and they would have to go and reconcile all the issues that were resolved with the code that was sitting in a repository. They would then check with each of the other engineers if there are any additional changes that need to be included in this release.

This was a long and drawn-out manual process that took a long time. Fast forward to now and Tim said CD is just a button you just have to press in Atlassian’s Jira to promote changes to production.

A fundamental part of CD is ensuring that your code is ensuring your code is in a releasable state, and Tim said Atlassian reflects that inside its own version control system. Atlassian developers use Git as its version control system because of its robust branching and merging functionality, where a portion of the code base is forked off to work more or less independently until it is in a working state and can be combined with the main product.

In every piece of work that developer do is never committed directly to master. Instead, it is tracked in a Jira issue with a branch until it is completed and ready to be merged into the master.

Tim said this approach provides developers with an isolated place where they can experiment freely and revert changes as needed. Once the branch code passes testing, it can safely be merged with the master. During all this, you still have a stable master branch without defects that is theoretically always ready to ship to customers.

Atlassian has embedded branching and merging into Jira in a way that is designed to practical and easy for developers to use. Creating a branch consists of clicking the “create branch” button and the developer will be redirected to the repository, where they are able to create a branch based on the issue they were just viewing.

Developers as users

For developers not used to the CI/CD methodologies, it can come with a slight learning curve. For one, it raises questions where in the cycle quality assurance, such as user testing, takes place.

Since CI happens almost immediately, or as soon as you push into your version control system, Tim said user testing usually takes place afterwards. Although Atlassian does run access programs with end-users, it is the developers who are responsible for monitoring successful features during production and tweaking them before rolling them out to a small part of the user base.

This means that at Atlassian a lot of the user testing happens internally. Tim says this is because Atlassian developers typically write tools they want to use internally.

The company still regularly sources and receives feedback from external customers, but because they have their own software development team that is quite large, Atlassian is essentially its own customer in terms of getting the user experience right.

That’s why user testing at Atlassian starts as soon as the feature branch gets merged into master. There will be teams of engineers using the new, recently-developer feature and immediately generating feedback.

Although it is nice to receive insights from other engineers, Tim said the downside is that you often have developers diving in to use the feature and telling you it’s not working correctly, when you already know it is still in development and just want some early feedback. That’s why developers can often find themselves clearly marking their experimental features as being experimental.

One of the important parts of the CI/CD cycle is the user intervention code review. At Atlassian, everyone does code review though it wasn’t always the case.

Tim said when he joined the company over a decade earlier he did pair programming, which is a type of code review where one engineer sits next to another who reviews it as you write it. As the company grew following acquisitions, developers progressed to doing code reviews that would include senior engineers and architects.

Nowadays, teams at Atlassian add up to four or five people to a code review. Anyone who is interested in reviewing can review, but only two approvals are needed to push a project into production.

Do more with less

Successfully adopting new methodologies and practices like CI/CD and DevOps is not easy. But with businesses no longer having months to deliver software, they have to find a way to make it possible in weeks or even days.

Planit’s DevOps services, built on decades of successful automation and process expertise, enables customers to improve software quality and deliver product faster. Contact us to find out how we can make meeting customer expectations on time, every time, a successful DevOps outcome for you.

Join The Discussion
Enquire About Our Services