Continuous Integration/Continuous Delivery (CI/CD)

From apppm
Revision as of 13:51, 3 May 2023 by S184230 (Talk | contribs)

Jump to: navigation, search
DevOps flow, multiple steps can be automated using CI/CD

Developed by Mikkel Anderson

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 optimizing workflows through integrated automation, testing, and collaboration, a purpose-built CI/CD platform maximizes 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 maximize the benefits of CI/CD by also implementing additional DevOps techniques like shifting left on security 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.

CI/CD is most definitely a must have in Agile Project Management and Scrum as it helps both the business side and the development side of the company to streamline software development and delivery.

Contents

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 on a regular basis 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.

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 app 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 [1] [2].

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. 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.

Implementation of CI/CD

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 "Make code reviews, branch management, and issue triaging work the way you want" [3].

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.

Flow chart of a simple CI/CD pipeline
  1. 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.
  2. The CI pipeline is then taking that code and checking if it can be build and tested.
  3. 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
  4. When the tests are successful, the code is then reviewed by other developers, which review and give feedback.
  5. If the other developers are okay with the new code, then it is merged on to the main branch on the central repository.
  6. 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 [4].

The GitHub Actions pipeline

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

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.github/workflows 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 still another that adds a label if someone opens a new issue.

Events e.g. commits new code - An event is a specific behavior 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, activity can originate from GitHub. You may also schedule a process to execute, submit to 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 packing 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 [5].

Limitations

CI/CD (Continuous Integration/Continuous Delivery) is not a specific term or concept that is mentioned in the PRINCE2 (PRojects IN Controlled Environments) methodology. PRINCE2 is a project management approach that offers a framework for project management from beginning to end. It gives guidance on the many stages of a project, such as project creation, planning, execution, monitoring and control, and project closure. PRINCE2 does not, however, prescribe how a project team should handle the technical parts of a project. As a result, the project team is free to use their own software development technique, including CI/CD approaches.However, as long as the CI/CD principles are aligned with the project objectives, timelines, and risks, they can be applied within a PRINCE2 project. The project team should also make certain that the CI/CD methods are in accordance with the project's governance and quality criteria.

In conclusion, while CI/CD is not specifically referenced in PRINCE2, it may be used inside a PRINCE2 project if it corresponds with the project's objectives and governance [6].

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 organization's 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

Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Office. 6th ed. Norwich, England: TSO, May 2017.

TODO

Provide key references (3-10), where a reader can find additional information on the subject. The article MUST make appropriate references to the and reference material provided in class – either incorporating it as a source, or critically discussing aspects that are missing from it but covered by this article. Summarize and outline the relevance of each reference to the topic (around 100 words per reference). The bibliography is not counted in the suggested 3000 word target length of the article.

References

  1. [https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment] Continuous integration vs. delivery vs. deployment (Visited 19/02/2023)
  2. [https://www.redhat.com/en/topics/devops/what-is-ci-cd] What is CI/CD? (Visited 06/04/2023)
  3. [https://github.com/features/actions] Github Actions (Visited 19/02/2023)
  4. [https://docs.gitlab.com/ee/ci/introduction/] CI/CD concepts (Visited 07/04/2023)
  5. [https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions] Github Actions Docs (Visited 3/05/2023)
  6. "Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Office. 6th ed. Norwich, England: TSO, May 2017."
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox