Continuous Integration/Continuous Delivery (CI/CD) - Revision history

S184230 at 14:03, 8 May 2023

2023-05-08T14:03:38Z

S184230 at 13:23, 8 May 2023

2023-05-08T13:23:54Z

← Older revision		Revision as of 13:23, 8 May 2023
Line 15:		Line 15:
	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.		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>.		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 ==		== 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 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.		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.
Line 44:		Line 44:
	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.		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.		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" />.

	= Implementation of CI/CD =		= Implementation of CI/CD =

S184230 at 13:15, 8 May 2023

2023-05-08T13:15:10Z

← Older revision		Revision as of 13:15, 8 May 2023
Line 15:		Line 15:
	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.		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.		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 ==		== Differences between continuous integration, continuous deployment and continuous delivery ==

S184230 at 12:27, 8 May 2023

2023-05-08T12:27:05Z

← Older revision		Revision as of 12:27, 8 May 2023
Line 40:		Line 40:

	==CI/CD's role in Scrum and DevOps==		==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.		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.

			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.		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.
Line 78:		Line 80:

	= Limitations =		= Limitations =
			The "A guide to the Project Management Body of Knowledge (PMBOK guide)” does not prescribe any specific software approaches, such as CI/CD, but instead provides a framework for fundamental project management practices. These are some limitations concerning the guide.

	CI/CD ~~(Continuous Integration/Continuous Delivery) is not~~ a ~~specific term or concept that is mentioned~~ in the PRINCE2 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.~~		'''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>.

	~~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~~ <ref name="~~PRINCE2~~">"~~Nigel Bennett and Axelos~~. ~~Managing successful projects with PRINCE2. Ed. by The Stationery Oﬀice~~. 6th ed. ~~Norwich, England: TSO, May 2017~~." </ref>.

	== Problems CI/CD does not solve ==		== Problems CI/CD does not solve ==
Line 94:		Line 95:
	= Annotated bibliography =		= Annotated bibliography =

	~~Nigel Bennett and Axelos. Managing successful~~ projects ~~with PRINCE2~~. Ed. ~~by The Stationery Oﬀice~~. ~~6th~~ ed. ~~Norwich~~, ~~England: TSO~~, ~~May 2017~~.		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.

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

	~~TODO~~		'''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’'

	~~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. Summarise~~ 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~~.		'''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 =		= References =

S184230 at 12:08, 3 May 2023

2023-05-03T12:08:55Z

← Older revision		Revision as of 12:08, 3 May 2023
Line 5:		Line 5:
	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.		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.		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.

	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~~.		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 =		= Overview of CI/CD =
Line 13:		Line 13:
	''Building a Successful CI/CD Pipeline with Agile Development and DevOps''		''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.		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.		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.
Line 67:		Line 67:
	[[File:GhActions.png\|600px\|thumb\|right\|Overview of GitHub Actions]]		[[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.~~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.		'''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.		'''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, 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.		'''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.
Line 79:		Line 79:
	= Limitations =		= 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.		CI/CD (Continuous Integration/Continuous Delivery) is not a specific term or concept that is mentioned in the PRINCE2 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 <ref name="PRINCE2">"Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Oﬀice. 6th ed. Norwich, England: TSO, May 2017." </ref>.		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 <ref name="PRINCE2">"Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Oﬀice. 6th ed. Norwich, England: TSO, May 2017." </ref>.
Line 86:		Line 86:
	'''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.		'''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.		'''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.		'''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.
Line 98:		Line 98:
	TODO		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.		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. Summarise 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 =		= References =

S184230 at 11:51, 3 May 2023

2023-05-03T11:51:35Z

← Older revision		Revision as of 11:51, 3 May 2023
Line 63:		Line 63:
	== The GitHub Actions pipeline ==		== The GitHub Actions pipeline ==

	''This section focuses on the technical aspect of how the GitHub Actions pipeline, is set up''		''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.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.		'''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.

S184230 at 10:22, 3 May 2023

2023-05-03T10:22:56Z

← Older revision		Revision as of 10:22, 3 May 2023
Line 61:		Line 61:
	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>.		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>.

	~~Hands on guidance on how to get started, and where to get more information.~~		== The GitHub Actions pipeline ==

	The GitHub Actions ~~pipeline:~~ <ref name="ghActionsDocs">[''https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions''] ''Github Actions Docs (Visited 3/05/2023)'' </ref>		''This section focuses on the technical aspect of how the GitHub Actions pipeline, is set up''

			'''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 <ref name="ghActionsDocs">[''https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions''] ''Github Actions Docs (Visited 3/05/2023)'' </ref>.

	= Limitations =		= Limitations =

S184230 at 09:52, 3 May 2023

2023-05-03T09:52:01Z

← Older revision		Revision as of 09:52, 3 May 2023
Line 59:		Line 59:
	# The CD pipeline builds and further tests the code, and if this is successful then the code is deployed to the customer.		# 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.		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>.

	<ref name="concepts">[''https://docs.gitlab.com/ee/ci/introduction/''] ''CI/CD concepts (Visited 07/04/2023)'' </ref>

	Hands on guidance on how to get started, and where to get more information.		Hands on guidance on how to get started, and where to get more information.

	~~Jenkins~~ <ref name="~~jenkins~~">[''https://~~www~~.~~techtarget~~.com/~~searchsoftwarequality~~/~~definition~~/~~Jenkins~~''] ''~~Jenkins~~ (Visited 19/02/2023)'' </ref>		The GitHub Actions pipeline: <ref name="ghActionsDocs">[''https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions''] ''Github Actions Docs (Visited 3/05/2023)'' </ref>

	~~The different pipelines: <ref name="jenkins" /> <ref name="ghActions" /~~>

	= Limitations =		= Limitations =
Line 80:		Line 76:
	'''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.		'''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.

	~~critically reflect on~~ the ~~tool~~/~~concept/theory~~ and ~~its application context. What can it do~~, ~~what can~~ it ~~not do? Under what circumstances~~ should it be ~~used~~, and ~~when~~ not~~? How does it compare to~~ the ~~“status quo” of the standards – is it part of it,~~ or ~~does it extent them? Discuss your article in the context of key readings / resources provided in class~~. ~~Substantiate your claims with literature~~		'''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 =		= Annotated bibliography =

S184230 at 09:31, 3 May 2023

2023-05-03T09:31:11Z

← Older revision		Revision as of 09:31, 3 May 2023
Line 1:		Line 1:
	[[File:CICD.png\|600px\|thumb\|right\|DevOps flow]]		[[File:CICD.png\|600px\|thumb\|right\|DevOps flow, multiple steps can be automated using CI/CD]]

	''Developed by Mikkel Anderson''		''Developed by Mikkel Anderson''
Line 9:		Line 9:
	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.		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.

	= ~~Background~~ =		= 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 <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 ~~answers~~ that a project manager could seek.		''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:		CI/CD is very important in modern day software development for several reasons:
Line 28:		Line 43:

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

	~~= Overview of CI/CD =~~

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

	= Implementation of CI/CD =		= Implementation of CI/CD =
Line 47:		Line 49:
	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.		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]]		[[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 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.
Line 69:		Line 71:
	= Limitations =		= Limitations =

	~~What problems~~ does CI/CD not solve ~~nor address?~~		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 <ref name="PRINCE2">"Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Oﬀice. 6th ed. Norwich, England: TSO, May 2017." </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 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.

	critically reflect on the tool/concept/theory and its application context. What can it do, what can it not do? Under what circumstances should it be used, and when not? How does it compare to the “status quo” of the standards – is it part of it, or does it extent them? Discuss your article in the context of key readings / resources provided in class. Substantiate your claims with literature		critically reflect on the tool/concept/theory and its application context. What can it do, what can it not do? Under what circumstances should it be used, and when not? How does it compare to the “status quo” of the standards – is it part of it, or does it extent them? Discuss your article in the context of key readings / resources provided in class. Substantiate your claims with literature

	= Annotated bibliography =		= Annotated bibliography =

			Nigel Bennett and Axelos. Managing successful projects with PRINCE2. Ed. by The Stationery Oﬀice. 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.		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.

S184230 at 13:36, 7 April 2023

2023-04-07T13:36:00Z

← Older revision		Revision as of 13:36, 7 April 2023
Line 47:		Line 47:
	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.		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\|~~right~~\|~~alt text~~]]		[[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 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 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		# 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		#* 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.		# 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.		# If the other developers are okay with the new code, then it is merged on to the main branch on the central repository.