7 min read

CICD: The Software Value Stream to your Customer

By Christopher Pepe on Aug 26, 2020 12:45:00 PM

DevOps Best Practices that connect you to your customer

Level Set of Terms

Before we dive into today's blog post, let's get familiar with these terms:

  • DevOps: A mix of cultural and technology practices to improve the use of software and technology-servicing customers.
  • Continuous Integration (CI): Traditionally, a developer spends their day coding, and at some point, they save (commit) their efforts within a development environment or an application branch. Think about a tree. Do you want one full of intertangled branches (loads of developers, all doing something, but getting in each other’s way), or do you want a well-balanced tree with a solid trunk? The same is true with coding, and CI allows for the integration of code to the trunk as fast as possible via agreed testing success. If the system fails (a diseased branch), then the feedback is fast enough that the code can be fixed and resubmitted. Note that the approval and commit steps are manual but the expectation is that they are performed daily at a minimum.
  • Continuous Delivery (CD): Removes the manual step and introduces automated approval based on testing success to push software to the trunk. CD eliminated the authorization wait time found in CI, thereby decreasing the feedback time. Faster feedback equals faster fixes, which underpins the culture of “if no defect found, then proceed to the next step in the software value stream.”
  • Continuous Deployment: I call this the ‘Trust My Developer’ process. Testing, packaging of code, release, and deployment (to the correct trunk or environment) are as automated as possible. We trust the process, the tools, and the quality of the code, and therefore we know that if there is an issue, we can also remove any code causing problems as quickly as possible. Feedback from the customer on the new applications or features is immediate.

How we created these practices: A bit of history

Software is what makes technology exciting, as it is often the software elements that make things happen, solve problems, or fulfill needs. It stands to reason then that the flow of software to a customer needs to be as fast as possible. Unfortunately, in many businesses today, that flow is a mixture of work, wait time, approval time, and probably rework. 

Does your software stream look like this?

  • Receive the request for something to be changed (new, feature or fix)
  • Wait
  • Get it approved
  • Wait
  • Pass it to a team as something to do
  • Wait
  • The team at some point begins to work on it
  • They finish their work and pass it to another team to add their code, or they give it to a test team
  • Wait
  • The test team schedules the environments for testing: code, security, performance, business continuity
  • Wait
  • After authorization, the code is deployed at the pre-set monthly or quarterly release
  • Wait
  • The code is released
  • Pray that it works and that things have not changed so much since the original request

Do you recognize your lengthy cycle of innovation? It doesn’t have to be this way, thanks to the practices of DevOps: Continuous Integration, Continuous Delivery, and Continuous Deployment.

Timewarp to today

What do your staff or customers want? Quality, fair cost, sustainability, resilience, and practicality. They want technology that helps them and, preferably, they want it now. Given the interconnectedness of the world, if a customer does not find satisfaction with you, then they go elsewhere within a mouse click. Your business peers can also do the same, hence this is how Shadow-IT (when peers circumvent formal IT processes) begins.

But what if:

  • Requests are assessed within a short time of receipt?
  • When the team began working on the request (either some aspect, if not the full request), was ready it for use within a sprint (two weeks to a month)?
  • As much as possible, the culture is that if no defect is found, the request moves to another team or goes live?
  • If the request can be improved, then how?

Jez Humble and Dave Farley best explained these practices in their book Continuous Delivery. Major software vendors such as Atlassian built their products based on these concepts (and have an excellent series of blog posts showing the why and how). It is becoming more and more difficult to find a business that does not depend on software, so why have processes that limit the use and improvement of your products or services? Sounds like nirvana (or a significant culture change).

Some of you by now are thinking that this can never happen where you work. I won’t quote how many times a day banks, Amazon, or even the latest start-ups that were born during the pandemic, deliver software to customers.

Tip: Look at sites from mature DevOps companies like Netflix and Amazon, and make that your goal so that you can work towards creating meaningful change within your organization. 

The CICDCD+ culture:

  • No defect goes live
  • No defect goes to the next environment
  • Ideally have no more than three environments; two is even better
  • Automate as and when we can
  • Test multiple times, as often as we can
  • Trust in the tools we use
  • Trust in the people that use those tools
  • Ability to roll back (uninstall code) as quickly as we can promote code
  • Limit the amount of work performed at any given time
  • Limit the size of our changes (make smaller changes?)
  • Changes are independent of the application or data (yes this is hard)
  • Every day is a new day during which we strive to improve the process

The Gap of Change: Are you ready?

CI implies that your organization wants to create and improve a pipeline of software to your customer. You also agree that management is going to allow the technology and governance processes to be available to develop, maintain, and improve the pipeline. CD also implies that you are satisfied with the flow of software, the timely feedback of information related to software value, and issues are resolved before working on other code. Automation is used to automate the approval of changes and the delivery to the appropriate environments or customers.

CD+ implies that you are content with both the culture and technology of software and how development and deployment have matured. You are ready to automate as much of the process as possible. Changes are small and independent enough that if there is an issue, they are quickly revoked. Minor changes also mean that customers get spoon-fed new software, one feature at a time. Documentation and recovery are both simplified, and the cost of software reduced.

Remember that there is no value in anything you do in technology until it is used to help someone fulfill a need or solve a problem. Until that time, everything you do or spend money on is a waste. Limit your waste by trying these practices. In the next blog, we will explore the metrics of CICDCD+, and the final blog of this series will provide tips from the leadership aspect.

If you have any questions in the meantime about any of the concepts discussed in this post, let us know

Topics: devops continuous-improvement customer-experience cicd
3 min read

Three Reasons Why Developers Love Docker

By Praecipio Consulting on May 6, 2016 11:00:00 AM

A smooth running production environment is a beautiful thing. But how do we get there? And how do we ensure that all of our production, staging/test, and development environments stay in sync in order to get there? Today, it seems like everyone in software development is talking about Docker and containers. In fact, according to the 2016 State of the Cloud Survey by RightScale, Docker adoption doubled from 13% to 27% in just one year. Furthermore, 35% of the organizations surveyed reported that they have plans to adopt it soon. 

Why has Docker adoption skyrocketed and how can those using Bamboo for continuous deployment reap the benefits? Check out three reasons why developers love Docker, and how it can provide value for your dev team. 

But first... 

What are Containers?

A Docker container packages software in a complete filesystem with everything it needs to run – such as code, runtime, system tools, system libraries – guaranteeing that it'll always run the same on any environment. Docker is all about creating consistency and encouraging collaboration. It revolutionizes how we share our environments the same way Git has changed code collaboration. At its core, Docker is about utilizing the least amount of operating system resources and dependencies needed to run an application. This focus on maximizing efficiency leads to a painless, more collaborative, and seamlessly integrated environment to test and deploy applications. 

Sourcewww.docker.com

1. Test without surprises

A crucial part of the development process is testing, whether on a local machine or in a virtual dev environment. With containers, every environment is exactly the same so changes and unexpected dependencies won't interfere with testing – saving developers time and energy from tweaking problematic environments and instances. 

Running containers on your local machine using Docker Quickstart Terminal lets you test in a consistent environment.  

2. Collaborate with consistency

Unexpected dependencies are already a hassle for one developer and becomes an even bigger headache when other devs enter the picture. Unknowns in an environment are amplified with each new team member – who knows what's on their machine or which version of Java they're running? With Docker, consistency facilitates collaboration. By starting with a known configuration in a common container, devs are always on the same page about which version to use; it's right there in the container.

Share your Docker Images with a registry like Docker Hub.

Source: https://hub.docker.com/_/hello-world/

3. Integrate with Atlassian 

Atlassian, the leader in enterprise software for collaboration and issue tracking, is the perfect complement to Docker. By pairing Docker's consistency with Atlassian's integration and automation, collaboration between development and IT ops becomes seamless. Using the new Docker Hub 2.0 with Atlassian's Bamboo, source code can be automatically built and deployed to an identical development, test, or even production environment. No more requesting environments from the IT ops teams; triggers will automatically fire from your approved pull request in Bitbucket to spin up a lightweight container in your QA environment almost instantly. Without the excess back and forth, you can go from source code to a running application in minutes. 

The Docker Task in Atlassian's Bamboo let's you run, build and deploy images and containers with ease.

Docker is picking up a lot of traction today and rightly so. Docker containers provide consistency in the turbulent world of software development environments. They allow dev and operations teams to get customers the applications they need now – all while providing a consistent environment that makes working together a whole lot easier. 

To learn more about how Docker and Atlassian can help your dev team work faster and smarter, contact Praecipio Consulting.

About Brendan Kelly

Brendan is a Consultant & Solutions Specialist at Praecipio Consulting where he enables the sales team through technical discovery, training and product demos. When Brendan isn't delivering best-in-class business technology solutions, he can be found in the Austin Green Belt hiking and bouldering. 

Topics: atlassian blog automation continuous-delivery bamboo docker optimization process standardize testing continuous-integration deployment development environment integration cicd

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us