Kicking Off Your CI/CD Implementation

CI/CD — Taking the plunge

Photo by Luca Bravo on Unsplash

In this blog I’ll explain how organizations should approach implementing a CI/CD framework. I’ll cover all bases but leave you to take from it what you will.

Why implement CI/CD?

Excellent question and there are many excellent answers. For example:

• Maximizing the use of Kubernetes deployment features
• Consistency of development and deployment environments
• Ease and speed of deployment and testing
• Reducing the chance of human error and bugs
• Built in security
• Validation and monitoring

Plus much, much more.

All of this leads to a greatly improved developer and end user experience as well as greatly improved time to market for new applications or features and fixes. When should you implement it? Ideally before you write a line of code but the next best time is now.

The dream

A new feature request comes in and is scheduled for development.

The developer codes and tests the new feature on a standardized environment and OS configuration, merges it with the main code branch (CI), and it is auto-deployed (CD), managed and scaled by Kubernetes to meet usage demands. This is where the bulk of a developer’s time is spent. No need to concern themselves with configuring the underlying application environment or operating system. Kubernetes will handle it.

The process comes with fully automated security, validation, deployment, monitoring, and feedback — thereby freeing up developers to do their preferred job of coding.

Planning your dream

First, you need to be clear why you want to implement a CI/CD framework to start with. This might be because you want to fully automate dev/ test / deployment / security / monitored environments, bring new products to market at lightning speed, reduce errors, improve developer and tester experiences, or for all the above reasons.

Once your goals have been set, this will drive what you do next. Get agreement from all stakeholders and be prepared to invest time and people up front to achieve your desired target outcome. It will pay off in the end.

Once this is done, define and priorities each objective i.e. what needs to be done, the benefits, and how you plan to execute on this ambition at a high-level. If possible, quantify the benefits.

Here’s an example:

Priority 1 — Objective: Standardize dev/test/deployment environments

• Benefits: Reduce the number of errors due to inconsistent environments by 20%, improve deployment times by 50%, better debug capabilities, increase time for developers to code by 15% due to not focusing on environment related bugs.
• How: Use of standardized and controlled container images at all times. Automated set-up and config of the same

Priority 2 — Objective: Reduce deployment time from x weeks to y days

• Benefits: Faster time to market, meet end user needs quicker.
• How: Use of automation and Kubernetes/Containers

Taking this approach makes it clear to all stakeholders what has to be done, and in the order needed to achieve your business needs.

Next plan the steps needed to achieve each prioritized item e.g.

Priority 1 — Objective: Standardized dev/test/deployment environments,

• Define standard environment containers images to be used i.e. libraries, security & access controls, access points (ports, protocols, users, etc) .
• Configure and test the container images to ensure they meet the defined requirements
• etc..

Priority: 2 — Objective: Reduce deployment time from x weeks to y days;

• Create CI pipelines to build, validate, deploy and test the app using the previously standardized images
• Configure Kubernetes to deploy and manage the images on the required environments
• etc…

At each step, make sure security and compliance, and process validation is put in place.

But before you start…

There are a few areas you will need to put some thought into -

1. Automation — if you can automate it, do so. Put the time, effort and resources on this up front. It will pay off in the long run in terms of saving time, and reducing the chance of human error. Areas to consider:

• Code analysis and linting — identifies potential security vulnerabilities (like SQL injection). and ensures a consistent style. Don’t overdo the automation as you can’t beat a good peer review :)
• Environment set up — Implement use of standardized environment configurations, and security and access control mechanisms across all development, test and production environments
• Application deployment including roll back on failure or on request
• Test execution on all environments
• Scaling of your environment to meet deployment or usage requirements
• Security and compliance — Monitor all activity at all times to ensure no untoward actions occur, including automated notifications to the right people/teams, and preferably automated responses if something does happen. An example would be data protection — automatically block someone storing data on Cloud Object Storage outside of permitted jurisdictions.
• Process compliance — if boxes need to be ticked before an action can be completed, automate where possible e.g. approvals. This might be overkill for some companies but sometimes it’s necessary.

2. Integration — if it is possible, integrate all stages of CI/CD to ensure you minimize the chance of human intervention which could result in errors causing problems and delays. If there’s existing integration capabilities such as an API, make full use of them.

3. Flexibility — your environment needs to be flexible enough to allow you to adapt it to your needs e.g. if you’re releasing a new feature and want to have a limited access approach to gauge user feedback (canary testing), use of Kubernetes as your deployment platform will easily enable this as well as ease of roll back if something fails or is deemed to not meet the user needs.

4. Security & Compliance — This should be built in from the start rather than as an after-thought at which stage it will prove harder to implement. Where to implement security and compliance & checks:

• When coding, merging, building, and deploying your code and the application
• Access Control — Ensure only the people who need access, get access — if your environments are on cloud, have you set up your Access and Identity Management correctly. Human error has been identified as one of the main causes of security breaches 1. Plan this one up front before doing anything. It will be painful to correct afterwards. Monitor it on an ongoing basis and remove access when no longer required.
• Cloud based environments — decide if use of shared resources is acceptable or otherwise. Make use of the the tools or services supplied by your cloud provider
• Some industries must meet regulatory compliance requirements e.g. Financial institutions or financial service providers. Automating monitoring of this will save your business a lot of time, effort and money if done right from the start.

5. Process Validation — Simplify the pain of process compliance up front. This will definitely save you team and if something goes wrong, you can quickly investigate where it may have gone wrong

6. Management and Monitoring — at each step of the process ensure you monitor what is happening so you know when something goes awry and can quickly roll it back or fix it. Use the results of the monitoring to fix issues or improve the process. Ignoring the feedback may prove costly and stop you from easily improving your implementation. Feedback should also be taken from the production system deployment and operation. This can be in the form of errors found during deployment or usage of the system by the end user e.g. canary testing or A/B testing.

So to summarize all the above… agree why you want to implement CI/CD, plan and priorities what needs to be done before doing anything, why you want to do it, and finally how you’re going to do it.

I wish you the best of luck implementing your own flavor of CI/CD, one that it is hoped will keep both your engineers and your clients happy.