View source for Continuous Integration/Continuous Delivery (CI/CD)

[[File:CICD.png|600px|thumb|right|DevOps flow, multiple steps can be automated using CI/CD]]

''Developed by Mikkel Anderson''

''The technical sections of this article need understanding in the subject of software development; nonetheless, the majority of the text is addressed towards project managers who manage software projects.''

Customer expectations are generally the same nowadays, regardless of your business: they want a quality product and efficient service. Annual releases with a pre-defined feature set packed into compact discs and given to merchants are a thing of the past. Delivering client satisfaction at the necessary pace necessitates a streamlined software development lifecycle that saves time, effort, and money wherever possible. Continuous Integration/Continuous Delivery (CI/CD) are at the heart of modern software development, allowing businesses to deploy new, working features earlier and more frequently.

The concept's premises include why CI/CD is a must-have for modern day software development, what role CI/CD plays in project management with all its advantages. CI/CD is a crucial component of [[DevOps]] and any contemporary software development methodology. By boosting an organisation's output, boosting efficiency, and optimising workflows through integrated automation, testing, and collaboration, a purpose-built CI/CD platform maximises development time. The CI/CD features can help in reducing the complexity of application development as they get bigger. Organisations may eliminate development silos (separation), let applications grow securely, and maximise the benefits of CI/CD by also implementing additional [[DevOps]] techniques like shifting left (plan, code, build & test) and tightening feedback loops. The concepts also include the core differences between Continuous Delivery and Continuous Deployment and lastly how to get started with CI/CD.

The importance of CI/CD lies in its ability to enable companies to produce high-quality software at a quicker rate while decreasing risks and increasing team cooperation. CI/CD is also important in [[Agile Project Management]] and [[Scrum]] as it enables project teams to produce results faster and with higher quality, while also encouraging collaboration, communication, and risk reduction. It benefits organisations by shortening the time required to introduce new features or upgrades to current ones, and decreasing costs while boosting cooperation.

= Overview of CI/CD =

''Building a Successful CI/CD Pipeline with Agile Development and DevOps''

CI/CD is a way of delivering applications to customers regularly by incorporating automation into the phases of app creation. Continuous integration, continuous delivery, and continuous deployment are the three primary ideas associated with CI/CD. CI/CD is an answer to the issues that new code integration can create for development and operations teams.

Specifically, CI/CD brings constant automation and tracking throughout the app's lifetime, from integration and testing to delivery and deployment. These linked practices are often referred to as a "CI/CD pipeline" and are backed by agile development and operations teams using i.e. DevOps <ref name="agile">Moran, A. (2015). Managing agile (2015th ed.)</ref>.

== Differences between continuous integration, continuous deployment and continuous delivery ==
The abbreviation CI/CD has several interpretations. The "CI" in CI/CD always alludes to continuous integration, which is a developer automation procedure. Successful CI means that new code changes to an app are created, evaluated, and merged into a common repository on a frequent basis. It is an answer to the issue of having too many branches in development at the same time that may conflict with each other.

The "CD" in CI/CD stands for continuous delivery and/or continuous deployment, two ideas that are sometimes used equally. Both are concerned with automating subsequent steps of the process, but they are sometimes used independently to demonstrate how much automation is taking place.

Continuous deployment, the other "CD", can refer to the automated release of a developer's modifications from the repository to production, where consumers can utilise these modification. It tackles the issue of an operation team being overburdened with repetitive processes that slows down the release of the application. It expands on the advantages of continuous delivery by automating the next step of the pipeline <ref name="cicd">[''https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment''] ''Continuous integration vs. delivery vs. deployment (Visited 19/02/2023)''</ref> <ref name="whatiscicd">[''https://www.redhat.com/en/topics/devops/what-is-ci-cd''] ''What is CI/CD? (Visited 06/04/2023)''</ref>.

= Why Project Managers Need to Understand CI/CD =

''Here are the answers to all of the CI/CD-related questions that a project manager could seek.''

CI/CD is very important in modern day software development for several reasons:
'''Rapid and consistent delivery''' - With CI/CD, development teams can deliver new software features and changes more quickly, allowing companies to react to consumer requirements more quickly and remain ahead of the competition. '''Improved quality''' - By integrating code changes into a common repository multiple times per day, CI/CD can aid in the identification of issues and defects early in the development cycle, making it simpler to resolve them before they become larger problems. '''Reduced risk''' - In CI/CD, automated testing and release procedures can help reduce the risk of human error and ensure that modifications are thoroughly evaluated before being deployed to production. '''Increased collaboration''' - CI/CD encourages more frequent code integration and input among developers, testers, and other users, which can contribute to better communication and a more effective development process. Overall, CI/CD is an essential component of software development because it enables companies to produce high-quality software at a quicker rate while decreasing risks and increasing team cooperation.

For several reasons, CI/CD is also important in project management:
'''Faster project delivery''' - By automating many aspects of the software delivery process, CI/CD enables project teams to produce results more rapidly. As a result, project managers will be able to make deadlines and accomplish project objectives more effectively. '''Greater awareness and control''' - Project managers can gain greater view into the state of code modifications, testing, and deliveries by adopting CI/CD processes. This enables them to detect possible problems early and take corrective action as required. Along side with the benefits of '''Improved quality''', '''Reduced risk''' and '''Increased collaboration''' CI/CD is very much essential in project management. Mainly because it enables project teams to produce results faster and with higher quality, while also encouraging collaboration, communication, and risk reduction. Which are some of the objectives a modern day project manager would like to achieve.

CI/CD is also benefiting the organisation, in the same ways as it is benefiting in project management:
'''Faster Time to Market''' - CI/CD shortens the time required to introduce new features or upgrades to current ones, allowing organisations to remain competitive in a quickly changing market, such as the software industry. '''Cost Savings''' - Because CI/CD automates the deployment process, it decreases the chance of developer mistakes and downtime, which may be costly for enterprises in terms of lost revenue and productivity. Overall, CI/CD enables enterprises to provide high-quality software more quickly and often, while decreasing costs and boosting cooperation.

To summarise the key advantages of CI/CD - It makes software development and deployment a much easier task not only for the developers, but also the project managers and the entire organisation. It increases the developers throughput, as they can focus on making new features and dealing with less bugs. It enables the project managers to get an overview of what has been made, and if there are any issues. The organisation benefits by saving cost, and innovating the entire organisation.

==CI/CD's role in Scrum and DevOps==
Both [[Scrum]] and [[DevOps]] approaches rely heavily on CI/CD. [[Scrum]] is an agile project management framework that helps teams deliver products iteratively and incrementally. It involves a set of predefined roles, events, artefacts, and rules that promote collaboration, transparency, and continuous improvement. [[DevOps]] is a software development methodology that emphasises collaboration, communication, and automation between development and operations teams to increase the speed, efficiency, and quality of software delivery. It involves a set of practices, tools, and cultural values that facilitate continuous integration, delivery, and deployment of software <ref>["http://wiki.doing-projects.org/index.php/Scrum”] "Scrum"</ref> <ref>["http://wiki.doing-projects.org/index.php/DevOps”] "DevOps"</ref>.

CI/CD facilitates the Agile concepts of continuous delivery and continuous improvement in Scrum. CI/CD helps teams to rapidly provide workable software in fewer cycles by automating the build, testing, and deployment processes, allowing for faster feedback and response to changing needs. CI/CD also contributes to the Scrum framework by allowing teams to evaluate and adjust their software in real time, resulting in higher quality and reliability. CI/CD is also a core approach in DevOps that facilitates the integration of development and operations teams. CI/CD helps to reduce silos between development and operations by automating the software delivery process, allowing for quicker and more effective cooperation. 

DevOps teams may also use CI/CD to produce software more often (Minimum Viable Product, MVP), with greater quality, and with less risk. CI/CD is a critical component of both Scrum and DevOps approaches, assisting teams in working more effectively and efficiently, delivering software quicker, and achieving higher quality and dependability <ref name="agile">Moran, A. (2015). Managing agile (2015th ed.)</ref>.

= Implementation of CI/CD =
The implementation of CI/CD can like in software be on the scale from very complex to very simple, it is up to the different development teams to figure out what is needed and to what extend. A very popular and current state of the art CI/CD workflow builder is '''Github Actions'''. This tool is not limited to what a CI/CD pipeline should be able to do, it will 
<blockquote>''Make code reviews, branch management, and issue triaging work the way you want.''</blockquote>  
according to their website <ref name="ghActions">[''https://github.com/features/actions''] ''Github Actions (Visited 19/02/2023)'' </ref>.

To begin the implementation of a CI/CD pipeline, one must first figure out which steps needs to be taken, in order for the source code to become a working program. Another step to consider is the fact that some programs might need different environments e.g. a Quality Assurance (QA) environment where internal testers can test, before the program is shipped to the customer. Disregarding the environment, it is possible to imagine a small step by step example where a developer is pushing new code to the central code repository, testing, verifying and shipping the new program. 

[[File:CICDflow.png|1200px|thumb|center|Flow chart of a simple CI/CD pipeline]]

# The first step is that the developer is making changes to the current code. This code is then pushed to a branch on the central repository. 
# The CI pipeline is then taking that code and checking if it can be build and tested.
# The result of the tests come back to the developer, either as an error message describing the problem, or a success message
#* If the test returns an error, the developer has to fix the error, and push the new code
# When the tests are successful, the code is then reviewed by other developers, which review and give feedback.
# If the other developers are okay with the new code, then it is merged on to the main branch on the central repository.
# The CD pipeline builds and further tests the code, and if this is successful then the code is deployed to the customer.

In the CI area it is possible to create a test environment if the developers or QA wants to visually test the program. It is of course also possible to add further or fewer steps to the pipeline, it is up to the needs of the developers and operation team <ref name="concepts">[''https://docs.gitlab.com/ee/ci/introduction/''] ''CI/CD concepts (Visited 07/04/2023)'' </ref>.

== The GitHub Actions pipeline ==

''This section focuses on the technical aspect of how the GitHub Actions pipeline, is set up.''

[[File:GhActions.png|600px|thumb|right|Overview of GitHub Actions]]

'''Workflows''' ''e.g. the entire CI/CD pipeline'' - A ''workflow'' is a programmable automated procedure that does one or more jobs. Workflows are defined by a YAML file that is checked into your repository and will execute when prompted by an event in your repository, manually, or on a predefined schedule. Workflows are specified in a repository’s <code>.GitHub/workflows</code> directory, and a repository can have many workflows, each of which can conduct a unique set of actions. For example, you may have one process that builds and tests pull requests, another that deploys your application whenever a release is made, and yet another that adds a label if someone opens a new issue.

'''Events''' ''e.g. commits new code'' - An ''event'' is a specific behaviour in a repository that initiates the execution of a workflow. When someone creates a pull request, opens an issue, or pushes a commit to a repository, for example. You may also schedule a process to execute, execute from a REST API, or run it manually.

'''Jobs''' ''e.g. change directory and run a command'' -  A ''job'' is a sequence of stages in a workflow that run on the same runner. Each step is either a shell script to be executed or an action to be performed. Steps are carried out sequentially and are interdependent. Because each step is executed on the same runner, data can be shared from one step to the next. For example, you might have a step that creates your application followed by a phase that tests the generated application. You can specify a job's dependencies on other jobs; by default, jobs have no dependencies and operate in parallel. When a job becomes reliant on another task, it will wait for the dependent job to finish before running. For example, you may have many build tasks with no dependencies for different architectures and a packaging job that is reliant on those jobs. The build tasks will run concurrently, and after they have all completed satisfactorily, the deployment job will begin.

'''Actions''' ''e.g. a collection of jobs'' -  An ''action'' is a GitHub Actions platform custom application that performs a sophisticated but regularly performed job. Use actions to help you decrease the amount of repetitive code in your workflow files. An action can get your git repository from GitHub, install the necessary toolchain for your build environment, or configure your cloud provider credentials.

'''Runners''' ''e.g. a virtual machine executing workflows'' -  When your workflows are activated, they are executed by a ''runner''. Each runner may only run one job at a time. To run your workflows, GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners; each workflow run operates on a new, freshly provisioned virtual machine. GitHub also provides bigger runners in a variety of combinations <ref name="ghActionsDocs">[''https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions''] ''Github Actions Docs (Visited 3/05/2023)''  </ref>.

= Limitations =
Although the "A guide to the Project Management Body of Knowledge (PMBOK guide)” does not prescribe any specific software approaches, such as CI/CD, this guide has been used as insight for a framework for fundamental project management practices. These are some limitations concerning the guide:

'''Constraints on resources''' CI/CD necessitates a large investment in automation technologies, infrastructure, and qualified staff, which can be difficult for companies with low resources. '''Organisational culture''' Collaboration, experimentation, and continuous improvement are required for CI/CD, which can be challenging to achieve in companies with strict hierarchies or isolated divisions. '''Regulatory compliance''' Some sectors, such as healthcare and banking, have stringent laws that necessitate significant testing and documentation, which might slow down the CI/CD process. '''Legacy systems''' Companies with legacy systems or complicated architectures may suffer technical debt, dependencies, or compatibility concerns while deploying CI/CD. '''Security and privacy''' To guarantee that sensitive data and intellectual property are secured throughout the software development lifecycle, CI/CD necessitates a strong security and privacy strategy, and often includes on-premise pipelines <ref name="PMBOK">"Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute." </ref>.

== Problems CI/CD does not solve ==
'''Security vulnerabilities:''' While CI/CD may help in the identification of security flaws early in the software development process, it cannot ensure that the product is totally safe. To assure the software's security, further security procedures such as penetration testing and code reviews may be required.

'''Alignment with business goals:''' While CI/CD can assist to deliver software fast and effectively, it does not guarantee that the software is aligned with the organisations business goals and needs. It is critical for the project team to verify that the software development process is in line with the overall strategy and objectives of the company. 

'''Remove needs for user testing:''' The software produced still needs to be verified with user testing. In most cases user testing cannot be skipped since it provides valuable feedback for the developers and operation team. 

CI/CD should be used instead of building and releasing software manually to customers, it should therefore be limited to replacing that step, and not any other steps in the DevOps cycle or project cycle.

= Annotated bibliography =

Since "Continuous Integration/Continuous Delivery” is a very specific subject, not many scientific references are to be found, but here are a couple of references that are worth reading when managing software projects. These publications were widely used to bridge the gap between project management and software development.

'''Moran, A. (2015). Managing agile (2015th ed.)''' - ''This book investigates agile methodologies from a project management standpoint, concentrating on strategy, execution, organization, and people. It determine the function of agile management in dealing with such change and unpredictability.''

'''DeMarco, T., & Lister, T. (2013). Peopleware (3rd ed.). Boston, MA: Addison-Wesley Educational''' - ''This book focuses on the users of the software and how to build successful software to people that are not used to making software. In most cases people have a completely different approach to software, than developers have. The book also focuses on the people developing the software, and how to make them work better as a team’'

'''Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix project. It Revolution Press''' - ''A novel that focuses less about the “dos” and “don’ts” but rather tells a story about an IT manager named Bill who is entrusted with saving a failing company's crucial IT project. Bill learns about the ideas and practices of DevOps, a philosophy that stresses cooperation, automation, and continuous improvement between development and operations teams, with the support of a team of coworkers and a mysterious mentor. Bill and his team overhaul the company's IT department and ultimately assist the firm achieve success via a series of hurdles and disappointments.''

= References =
These references were utilised in addition to the annotated bibliography, mostly for implementation and to start a debate and offer a broader perspective on the issue.

<references />

[[Category:Project Management]]
[[Category:Agile Project Management]]
[[Category:IT]]
[[Category:Agile]]
[[Category:Software Project Management‏‎]]
[[Category:Change Management‏‎]]
[[Category:Continuous Improvement‏‎]]
[[Category:Leadership‏‎]]
[[Category:Lean Management‏‎]]
[[Category:Performance Management‏‎]]
[[Category:Process Improvement‏‎]]
[[Category:Project Management‏‎]]
[[Category:Risk Management‏‎]]
[[Category:Software Project Management‏‎]]
[[Category:Teamwork‏‎]]