What does the CD in CICD actually mean?

It’s occurred to me fairly recently that there’s sufficient confusion about what the CD in CICD stands for, to warrant some simple explanation. I’m not even certain that people generally understand the CI part either. I’ve noticed on a few occasions developers tend to say, “A CICD pipeline is an automated way of delivering code into production.” I feel this is often interpreted as, “you commit code over here in your repository, and it automagically pops up in production over there.”

“What on earth could possibly go wrong with that?” the system operations team might ask sarcastically, turning distinctly green then pale at the thought of developers having ultimate control over production releases. I’ve also noticed non-developers ask, “Is it Continuous Delivery, or Continuous Deployment?” Is there even a difference? It seems a number of people interchange Delivery and Deployment without really understanding what each of them actually is. Isn’t this just typical developer double-speak for exactly the same thing?

To provide some historical context to this explanation, it’s useful to understand software development life cycles before Virtualisation and Cloud. Right up until the mid-2000s, software feature releases were typically very slow. Products might have gone four years before they got an update, and the savvy never installed a “dot-one” (.1) release, let alone a dot zero (.0). Frequently they were buggy and unreliable. It often wasn’t until a “one- dot-two” (1.2) release that people started getting any confidence. Even then, that only ensured catastrophic bugs were eliminated. Other glitchy behaviours often still existed but didn’t contribute to a total loss of work.
“You do back up your work every half hour right?” was the catch cry long before Cloud, autosave and versioning were as widespread as it is today.

A significant change that virtualisation helped bring about, was the ability to more cheaply run a non-production staging environment. A place to test out new changes before releasing them into production. Cloud via infrastructure as code makes non-production environments even faster, easier and cheaper to provision for testing purposes. The key to an effective staging environment is that it’s as Production-like as possible. This helps avoid embarrassing and costly “roll-backs” when code changes don’t behave in production as expected because there was too much variation between prod and non-prod.

Running in parallel to these infrastructure changes was the development and rapid adoption of software version control systems. In the bad old days, files were versioned by either commenting out old lines of code and introducing new lines. Alternatively, old files on production servers were renamed, and new files introduced in their place. It was less than ideal and alarmingly widespread. “When was the last backup done?” wasn’t something you wanted to hear in a development team. It often meant somebody had overwritten something they shouldn’t have.

Version control in the form of SVN, then later Git and other alternatives allowed a new copy of a code file to be added to a repository, and the old version kept completely intact. What’s more, the developer could comment during the commit, what had been changed.
This lead to the practice of Continuous Integration (CI), where developers could collaborate together more rapidly by sharing small code changes via the version control repository, and by doing so, minimise the impact each code change had on others. Everyone was effectively working on the same code base, rather than having separate copies that diverged more and more widely, the longer each developer worked on their private copy of the code.

This brings us then to Continuous Delivery which is the automatic build and test of committed code changes with the aim of having production ready features available for release. Getting to Continuous Delivery after the successful implementation of Continuous Integration is relatively straight forward using AWS Services. By using Code Pipeline to automate the test and build of code commits, most of the tooling required is readily available.
AWS services like Elastic Beanstalk make it incredibly simple to replicate production application stacks into non-production environments for testing. AWS OpsWorks and CloudFormation can greatly simplify the reproduction of more complex application stacks for production-like staging.

Many organisations get to Continuous Delivery and don’t adopt Continuous Deployment. They either use a manual authorisation step to deploy changes into production or a semi-automated delivery approach of code into production. Continuous Deployment then is the automatic deployment of production-ready code into production with no manual interventions. If changes fail the build and test processes, they are rejected and sent back to the development team for revision. If however, all changes pass the test, they are automatically deployed into production, and this is continuous deployment.

The fundamental key to all this working well is small frequent changes. The historic issue with large complex changes over an extended period of time was that the root cause of any particular issue was extremely difficult to pin down. This made people reluctant to release changes unless it was absolutely necessary. With the collaboration made possible by Continuous Integration, it ensures everyone is working on a single code base. This prevents accumulative errors common when everyone is working in isolation on big changes.

So there is an important distinction between Continuous Delivery and Continuous Deployment. The latter can be arrived at in an incremental manner after successfully adopting CI, then getting continuous delivery and testing to a robust enough point that well vetted, small feature changes can be continuously deployed into production.

Consegna have significant experience in helping organisations adopt CICD successfully. If you’d like to find out more information, email hello@consegna.cloud.

NZTA All-Access Hackathon

Consegna and AWS are proud to be sponsoring the NZTA Hackathon again this year. The event will be held the weekend of 21 – 23 September.

Last year’s event, Save One More Life, was a huge success and the winner’s concept has been used to help shape legislation in order to support its adoption nationally.
The information session held in the Auckland NZTA Innovation space last night, provided great insight into this years event which focuses on accessible transport options, in other words making transport more accessible to everyone, especially those without access to their own car, the disabled, and others in the community who are isolated due to limited transportation options.

The importance of diversity among the teams was a strong theme during the evening. For this event in particular, diverse teams are going to have an edge, as Luke Krieg, the Senior Manager of Innovation NZTA, pointed out, “Data can only tell you so much about a situation. It’s not until you talk to people, that the real insights appear – and what the data alone doesn’t reveal also becomes evident.”

Jane Strange, CX Improvement Lead NZTA, illustrated this point nicely with a bell curve that shows the relationship between users at each extreme of the transport accessibility graph.

Those on the right with high income, urban location, proximity to and choice of transport options invariably define transport policy for those to the left of the curve who are those with low income, located in suburban or rural areas, who are typically more isolated and have fewer transport options.

Luke also stressed how much more successful diverse teams participating in Hackathons usually are. As these are time-boxed events that require a broad spectrum of skills, technology in and of itself often doesn’t win out. Diverse skills are essential to a winning team.

For more information and registration to the event, please visit https://nzta.govt.nz/all-access

 

Why Cloud is Relevant to Your Business Today

As the newly appointed ICT Manager for a large government agency, Jeff was keen to make his mark quickly and decisively in his new role. Looking at the IT spend over the last three years, he could see that in spite of the market shifting considerably, the agency had been paying exorbitant amounts for application hosting. The market had trended downwards with pressure from large Cloud providers like AWS. Looking at their hosting arrangements more closely, Jeff could not only see their costs remained largely unchanged but also, service reliability had been steadily declining. This project looked like an ideal candidate to reduce cost, increase service levels, and make the mark he wanted.

After looking at the current environment carefully, a current rebuild of the primary public website for the agency appeared to be a good choice. The site was currently in development using AWS services. The development team had chosen AWS for development due to its low cost, well within their budget. Far more compelling to them was the speed with which the developers could provision and utilise the necessary resources. What would typically take internal IT weeks to provide for the developers could be accomplished inside a day using AWS management tools and company best practice.
Using managed services such as AWS Elastic Beanstalk, not only did the development team have ready access to a low-cost development environment they could provision on demand. They could also run parallel application stacks for testing. That just wasn’t possible using their existing infrastructure that was difficult to access and manage. As such, the AWS services allowed new configurations to be tested quickly at a fraction of the cost of traditional infrastructure. Cents per hour, versus a few hundred dollars a month.

With the application completed, launch day and migration commenced. Fortunately, Jeff had identified that the team needed an AWS partner to assist with the migration. This lead to the realisation that a scalable architecture was required to support the fluctuating demand on the website. With the right design, the right AWS partner, the site was migrated and delivered a 75% saving on the former hosting costs. With the automated scaling and monitoring, AWS services provided as part of the production environment, site outages dropped to less than 1% over first few months of operation, improving even more over time. The site had gone from 2 – 3 outages per month on the old hosting, due to network and other issues, to no unscheduled outages from one month to the next.

At this point, one would think this would be the end of the story. The primary production site was on AWS at a fraction of the former cost. Service levels were higher than they ever had been. The new problem that was beginning to emerge was cost control and environmental regulation.

With the success of this project, Jeff’s teams started moving more and more projects to AWS. As more teams in the organisation also adopted this approach, keeping an eye on resource usage started becoming more challenging. Managing what teams and individuals had access to resources was also emerging as a challenge. The situation Jeff was finding himself in after an initial easy win is quite common. Many companies who discovered server virtualisation during the mid-2000’s also learned technology on its own can create all new challenges nobody had previously anticipated.

The simple answer to why Cloud is relevant to your business today is the agility it provides and the transfer of CapEx to OpEx. Not to mention the tangible cost savings you can make. What’s important for ICT managers to understand, however, is the importance of a structured approach to Cloud Adoption. Not every workload is going to be a suitable candidate for migration. Ongoing success requires the implementation of a Cloud Adoption Framework (CAF) and the establishment of a Cloud Centre of Excellence (CCoE). Neither of which need to be as daunting as they sound. The CAF examines your current environment and assesses what workloads would work in the Cloud. It highlights six perspectives around Business, People, Governance, Platform, Security, and Operations. In so doing, it ensures thought is given to each of these within the context of Cloud. What training do your people need for example, when a particular application gets migrated to the Cloud? How would their roles change? What operational support would they need?

A CCoE should be seen as the thought leadership and delivery enablement team that will help plan and execute on the CAF. It usually consists of SMEs from each principal area the CAF examines. By choosing an AWS Consulting Partner like Consegna, who understand this pragmatic, structured approach to cloud adoption and digital transformation, ongoing long-term success starts from a solid foundation.

The discoveries Jeff made during his journey to Cloud are being made by ICT managers on a near-daily basis. An increasing number of Jeff’s peers understand that Cloud is a timely and necessary step to reduce cost and increase agile productivity. Those with that extra slice of understanding and knowledge are working with partners like Consegna to do Digital Transformation the smart way. Putting CAF and CCoE at the forefront of their journey, and seeing great successes in doing so.

Why is CAF Critical to Cloud Adoption?

An all too familiar scenario playing out in numerous organisations today is a rapid push onto the Cloud.  Typically this entails a technical division getting approval to migrate a workload onto to the Cloud, or establish a new project on AWS EC2 instances.

Fast forward a few months and the organisation’s cloud adoption seems to be progressing fairly well.  More and more teams and applications are running on AWS, but it’s around this time that cost and management have started spiralling out of control.  A quick survey of the organisation’s AWS account reveals there are users, instances and various other resources running out of control “on the cloud”.  The typical issues many organisations have wrestled with in their traditional infrastructure space has been directly translated onto the Cloud.  Now the financial controller and other executives are starting to question the whole Cloud strategy.  What exactly has gone wrong here?

Whether you’re prototyping a small proof of concept (POC) or looking to migrate your entire organisation into the Cloud, if you fail to adhere to a Cloud Adoption Framework (CAF) and form a Cloud Centre of Excellence (CCoE), it won’t be a case of if the wheels fall off the wagon, but when.

Think of the CAF as a structured roadmap that outlines how and when you’re going to migrate onto the Cloud, and the CCoE as the project leadership team who will be able to execute the CAF in a manner that will guarantee results.

The CAF looks at Cloud Adoption from six different perspectives. Business, People, Governance, Platform, Security and Operations.

 

It ensures that no matter what project you have in mind, the broader implications of Cloud adoption are highlighted and worked through.  If you’ve ever been privy to the disaster an ad-hoc technology lead adoption results in, you’ll truly appreciate how critical CAF is to successful Cloud transformation.

Consegna specialise in running CAF workshops for organisations to ensure success with end to end Cloud transformation, both from a Business and Technical perspective, for complete Cloud adoption.  For a coffee and chat about CAF and how it can ensure the success of your Cloud migration and digital transformation, contact sales@consegna.cloud for a catch up.

How Do You Assess A Trusted Cloud Partner?

When it comes to digital transformation and cloud adoption, a trusted advisor with the right experience is a crucial component to your success.  How do you evaluate your options?

Case studies such as the one recently published by Consegna.Cloud, highlight the challenges and solutions provided, giving key decision makers essential insights into the scope and scale of other projects in relation to their own.

 

Case Study

 

Key points of interest in the case study are identifying the complexity of the project.  For example, in the QV case study Consegna recently published, the existing systems were almost twenty years old, so a mature system with a lot of legacy components.  Thus, a high level of complexity.

Case studies also highlight the key benefits the project delivered.  In the case of QV, over 50% savings on Infrastructure costs alone.  Please look for these key metrics as you read through the case study.

Such artefacts are useful in establishing the evidence based capabilities that Consegna, a trusted Cloud advisor, possess.  Feel free to contact the Consegna team to ascertain how your project compares to the QV project.  Simply email sales@consegna.cloud  to start the conversation.

Consegna Official Launch

Last Thursday evening Consegna were proud to host clients and business partners to their official launch at Seafarers in Auckland.

CONSEGNA_LAUNCH-38

The evening was a great success with Tim Dacombe-Bird, Country Manager of AWS speaking, along with customer presentations from Liz Cawson of AMP and Duncan Reed from QV, both highlighting the working partnerships they have with Consegna and AWS.

Thank you to AWS, Megaport & Symantec for their support on the night. More photos on https://lnkd.in/g9Xe_i6