Software Development: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(82 intermediate revisions by the same user not shown)
Line 1: Line 1:
=DevOps=
=Internal=


A collaborative process enabled by automation where ''application development'', ''QA'' and ''Operations teams'' jointly accelerate delivery of new business application and services. DevOps emphasizes ''collaboration'' and ''cooperation''.
* [[Software Engineering]]


=CICD=
=Overview=


==Continous Integration (CI)==
With any of the delivery modes below, the provider controls and manages some portion of the technology stack. The customer manages the portion of the technology stack that is not managed by the provider. The benefit is that the customer controls the design of its portion of the stack.


Continous Integration is a software development practice that involves the following:
Software development makes [[Software_Architecture#Overview|software architecture]] to materialize, and the set of rules and practices that go into software development belong under the larger umbrella of [[Software_Engineering#Software_Development|software engineering]].
* Verifies build integrity by checking if the source code can be pulled from repository and built for deployment. The build process may include compilation, packaging and configuration.
* Runs and validates the unit tests: executes all unit tests created by developers and validates the test results. This step insures that the source code was not broken as a side effect of the commit.
* Runs and validates the integration tests.
* Identifies problems and alerts the teams.


In the DevOps culture, CI is mandatory, and it performed automatically by a tool that runs automation scripts to eliminate all human intervention during the CI process.
=A/B Deployments=


The CI process requires a source code repository and a continuous integration server, that pulls code from the source repository and runs the build. Developers must check in as often as possible, every time a new piece of functionality that is verified by unit tests that pass is added. The build must be completely automated and must run without human intervention, and it must be fast.
{{Internal|OpenShift_Application_Operations#A.2FB_Deployment|A/B deployment with OpenShift}}


Testing - especially the integration testing - must be done in an environment that is as close to production as possible.
=Twelve-Factor Application=


The CI process provides rapid feedback on the state of the project, each unit test or integration test-verified assertion that gets broken by a commit is immediately shared with the entire development team. The process is run every time there's a commit, presumably many times a day. Every member of the team must be able to easily access the build results.
{{Internal|12 Factor App|Twelve-Factor Application}}


The build process should generate software that can be deployed at any time - a good release candidate.
=Semantic Versioning=
{{Internal|Semantic Versioning|Semantic Versioning}}


==Continous Deployment (CD)==
=Good Reads=
 
* https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
 
=Developing Applications for the Cloud=
 
{{Internal|Developing Applications for the Cloud|Developing Applications for the Cloud}}
 
=Microservices=
 
{{Internal|Microservices|Microservices}}
 
=Infrastructure as Code (IaC)=
 
''Infrastructure as Code'' is an approach to IT systems infrastructure management, where various elements of the underlying hardware infrastructure are represented as programming constructs rather than physical hardware. This approach can be used in combination with automation tools to provide the ability to provision infrastructure in a repeatable and reliable manner.
 
=Code Review=
 
{{Internal|Code Review|Code Review}}
 
=Simplicity=
 
* https://thinkingsideways.net/code/2019/03/24/simplicity-over-flexibility.html
* https://www.infoq.com/articles/simplicity-manifesto-development
 
=Scrum=
 
* https://medium.com/@aevitas/the-tax-you-are-paying-for-using-scrum-50f12298b422
 
=Domain-Driven Design=
{{Internal|Domain-Driven Design|Domain-Driven Design}}
=Software Security=
{{Internal|Software Security|Software Security}}
=Consistency=
* https://medium.com/@jgefroh/why-consistency-is-one-of-the-top-indicators-of-good-code-352ba5d62020
 
=Software Development Practices=
* [[Continuous Delivery#Overview|Continuous Delivery]]
 
=To Process=
 
* Grady Booch - Building the Enchanted Land https://www.infoq.com/presentations/ai-best-practices. Health of the system: "do you have a regular process of release?" "do you have a sense of architecture?"
* [[Feature Toggle]]

Latest revision as of 23:14, 2 July 2023

Internal

Overview

With any of the delivery modes below, the provider controls and manages some portion of the technology stack. The customer manages the portion of the technology stack that is not managed by the provider. The benefit is that the customer controls the design of its portion of the stack.

Software development makes software architecture to materialize, and the set of rules and practices that go into software development belong under the larger umbrella of software engineering.

A/B Deployments

A/B deployment with OpenShift

Twelve-Factor Application

Twelve-Factor Application

Semantic Versioning

Semantic Versioning

Good Reads

Developing Applications for the Cloud

Developing Applications for the Cloud

Microservices

Microservices

Infrastructure as Code (IaC)

Infrastructure as Code is an approach to IT systems infrastructure management, where various elements of the underlying hardware infrastructure are represented as programming constructs rather than physical hardware. This approach can be used in combination with automation tools to provide the ability to provision infrastructure in a repeatable and reliable manner.

Code Review

Code Review

Simplicity

Scrum

Domain-Driven Design

Domain-Driven Design

Software Security

Software Security

Consistency

Software Development Practices

To Process