CI/CD explained to SALES

Within IT, the fast and predictable delivery of new functionality is called ‘CI/CD’ (Continuous Integration/Continuous Delivery). CI/CD is difficult to explain to anyone who is unfamiliar with the world of software development and management. I discovered that this modern IT delivery process is in many ways comparable to the better known tendering or bidding process. Especially in organisations that want to provide their customers with consistent and qualitative tenders that are issued on time. I will explain this on the basis of the CI and CD sub-processes, first based on the software world and then on the tendering world. And since the CI/CD process is very effective due to automation, when well organised, I will give some ideas on how to improve the bidding process along the way.

Continuous Integration (CI) - Integrate

The goal of CI activities is to work as efficiently as possible towards one consistent delivery (release). Because several employees work simultaneously on partial deliveries that are (integrally) tested and delivered as a consistent whole, we speak of Integration. Continuous Integration consists of five phases, plan, code, build, test and release, which can be compared to planning, writing, freezing, reviewing and bundling in the bidding process.

Plan - Planning

‘Planning’ at CI/CD is no longer simply a matter of dropping activities and milestones into a project team. It mainly concerns prioritising the customer’s desired functional and non-functional requirements. The team assesses how complex the work is and what expertise is necessary to deliver results within a defined period of time. This work is divided among team members and (partial) delivery times (sprints) of up to two weeks.

The start of the bidding process is similar. The customer and the customer’s demand are analysed and the work is distributed among the members of the bid team. The bid manager plans fixed (partial) delivery times that are a maximum of two weeks apart. Planning is a continuous process with its own feedback loop to improve the predictability of the team.

In an agile bid team, give the commercial manager the role of product owner and the bid manager the role of scrum master.

Code - Write

In a development team, several developers work in parallel on realising new functionality. The code they write is recorded in a common version control system (Git). Keeping one version of the truth in a fixed place is an absolute prerequisite for integration.

In a bid team, too, several employees work simultaneously on a tender. For example, a project leader, architect, account manager, service or contract manager and bid manager. They collect and write texts that eventually lead to an integrated tender.

Also employ a version control system in a bid team for frequently used text fragments, templates and standard calculation models. Practice shows that a lot of time is lost in document management and rewriting texts. Make the bid manager a ‘Git manager’.

Build - Freeze

Building through programming (code) is done less and less. Developers model and use reusable components such as existing services (APIs), program libraries (code libraries) and programmingframeworks. In addition, it is not only about functional code, but more and more about configuration files and scripts. The construction process consists of assembling components made in-house and existing components in a reusable and testable unit.

Reusable components are also used within the bid team. Examples include a document template, a price calculation model, a standard contract, a product and service catalogue, etc. The development and registration of standard building blocks has great advantages when composing the final tender. I named this phase ‘freezing’, because the essence of the building process is the delivery of reusable (i.e. tested) building blocks. Every professional bid team has a library (or as their software colleagues might call it, repository) with standard building blocks.

Try to collect the documents that make up the tender in a single configuration file. And please give me a call if you have created the equivalent of a package manager: a tool that compiles your tender based on the configuration file!

Test - Review

A developer must test the delivered and ‘frozen’ building block before it can be included in the final delivery. This testing not only takes place at the end of the build process (unit test), but also during code writing (code review) and at many other moments in the delivery process. There are integration tests, security tests, load tests, acceptance tests, tests for specific user groups, etc. Within CI/CD, automated testing is carried out using modern tooling.

There are similar review moments in the tendering process, although they are not automated. The goal is to guarantee the quality of the parts and the whole and thus to realise a good quality tender.

Plan the review moments in advance and let the reviewer describe in advance, what he wants to see in the text. After the review, see to what extent it has been successful. Determining this coverage is an important indicator of the quality of the delivered work and can further automate the revision process itself.

Release - Collect

What the developer does on parts, also happens over the delivered parts (artifacts) of the team as a whole. The end result of the CI process is a release. This release is automatically delivered to the end user via the delivery processes (CD). The release process forms the bridge to the more operational processes.

The bundling of the products to be delivered within the tendering process is usually carried out by the bid manager. As with software, merging the total tender is not an easy task. Monitoring the consistency (e.g. use of words, but also, for example, aligning the approach with price and solution) is a particular challenge.

Within the CI/CD process, the composition of the release and the way in which the components go through the entire chain (pipeline) is recorded in configuration files and executed automatically. For the bidding process this means an automated workflow. Attempt to support your bidding process with workflow software. In addition to the speed of delivery, this will certainly improve the quality of the tender.

Continuous Delivery (CD) - Deliver

CD activities are all about delivering functionality, a product or service. Continuous Delivery consists of four phases: release, deploy, operate and monitor – similar to bundling -, distributing, maintaining and measuring in the bidding process.

As you may have noticed, the Release/Collect phase falls into both CI and CD. The arrow of the CI process (see figure) ends in the middle of the release process, because it is precisely in this phase that Development and Operations have to cooperate intensively (DevOps). In an optimal situation, there is no interruption; business, developers, administrators, security/quality employees and customers work together from the beginning. At Solvinity, we call the automation of the entire supply chain ‘Integrated Delivery’ and working with multiple parties across company walls ‘Stretched DevOps’.

Deploy - Distribute

The transport and installation of the new functionality often starts on the developers’ laptops and ends in production via test and acceptance environments. The distribution of new functionality has undergone an enormous change with the introduction of containers as transport vehicles. The use of containers, as a more efficient form of virtualisation, also fits in seamlessly with the incremental activities within the software development. The development of small functional services (microservices) that communicate with each other has major advantages in terms of scalability, availability and portability. Functionality, packaged in a container, can be delivered in smaller and more controlled steps to specific user groups.

As a bid team, you ultimately deliver one set of files. For this purpose, the documents are often first published in PDF format. The advantage of a PDF document is that it can be read on all possible devices and that, as with containers, you are platform-independent. By splitting the delivery into several PDF files, you can easily replace a single PDF without having to perform a completely new delivery. Finally, a PDF ensures that third parties cannot change the content. A new version means the delivery of a new PDF.

Open the PDF to check it visually. Headers and footers in particular are less noticeable in an editor.

Operate - Maintain

CI/CD goes beyond building, testing, integrating, releasing and rolling out new functionality. Once the software has been made available, it must also remain available, be secure and offer good performance. Safeguarding these non-functional aspects traditionally falls within the domain of the administrators (Ops). But here too, there must be intensive cooperation between Dev and Ops. Starting from the design of the functionality, these quality aspects must be taken into account. Therefore, the CI/CD process does not stop with the roll-out of software and there may be no proverbial ‘Chinese walls’ between development and management.

The submission of the tender also does not mean that the bid team’s work is finished. A deal will be followed by change requests that have to be in line with the initial tender; employees will want to understand what has been delivered and will want to further develop partial products, etc. In the current bidding process, partly due to the bonus incentive that is given when the deal has been won, you often see too little attention for feedback from the management phase. The distance between sales and operations is then comparable to the distance between development and operations.

Successful bid teams continue to maintain a relationship with the users and administrators of their proposals. So during the management phase as well, check to what extent the original tender is still being followed up on. What went well and what could be improved?

Monitor - Measure

The success of a new release must be measured. Is the new functionality actually being used? Are users satisfied and more productive? Have any new wishes and requirements emerged? The measurement result of these aspects forms the input for new releases and the optimisation and innovation of the services. This completes the circle and brings us back to the planning process.

A bid team will want to know why a deal has failed or succeeded. It will want to maintain the connection to the operation and customers in order to be able to submit successful tenders. The collection and analysing of successful, but above all also unsuccessful, bidding data can help enormously in qualifying future deals and thus save a lot of time and money. Both processes ultimately revolve around the continuous and efficient delivery of the best fitting solution to the customer.

Do you have questions about the implementation of CI/CD or do you want to have a chat about improving the bidding process? Please contact klaas.heek@solvinity.com