Software Development: Difference between revisions

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


* [[Software Architecture]]
* [[Software Engineering]]
 
=Programming=
 
{{Internal|Programming|Programming}}
 
=Cloud Service Delivery Models=


=Overview=
=Overview=
Line 13: Line 7:
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.
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.


==External==
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]].
 
* NIST definition of Cloud Computing http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
 
==Infrastructure-as-a-Service (IaaS)==
 
The IaaS delivery model lets the user of the service to provision processing, storage, networking and other computing resources on which they can run O/S and applications. This includes the hardware and the virtualization layers. The service users do not control the underlying computing infrastructure except select networking configuration or perhaps the physical location of the resources at gross geographical level. On the other hand, they control - but they must install and manage - the operating system, the middleware and the application code. Infrastructure as a service is targeted at teams that are building out infrastructure.
 
Example: Amazon Web Service, IBM Cloud.
 
==Platform-as-a-Service (PaaS)==
 
"Platform as a Service" describes an additional level of services layered on top of an [[Software_Development#Infrastructure-as-a-Service_.28IaaS.29|infrastructure as a service]] foundation. These services include operating systems, database, middleware, etc. "Platform as a Service" are platforms for building and running custom applications, and are targeted at application development teams. The customer controls the design of the application, but the management of the platform stack is abstracted away. The customer can focus on functionality design and coding.
 
PaaS is also named "cloud application platform".
 
Example: OpenShift, Google app engine.
 
External:
 
* http://en.wikipedia.org/wiki/Platform_as_a_service
* Salesforce - What is PaaS? http://www.salesforce.com/paas/
* http://www.infoq.com/presentations/Java-in-the-Cloud-PaaS-Platform-in-Comparison
* Netflix Adrian Cockcroft on Architecture for the Cloud http://www.infoq.com/interviews/Adrian-Cockcroft-Netflix
 
==Software-as-a-Service (SaaS)==
 
In this model, the software is the actual service offered on the web (salesforce.com, Intuit Quickbooks). The customer does not need to manage anything, but they also do not control anything, including the design of the application. This works well, unless the customer needs functionality that is not available in the application.
 
=DevOps=
 
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''.
 
=CICD=
 
==Continous Integration (CI)==
 
Continous Integration is a software development practice that involves the following:
* 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.
 
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.
 
Testing - especially the integration testing - must be done in an environment that is as close to production as possible.
 
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.
 
The build process should generate software that can be deployed at any time - a good release candidate.
 
[[Jenkins]] is a CI/CI engine.
 
[[SonarQube]] is a static code analysis tool.
 
==Continous Delivery (CD)==
 
Continuous delivery is a software development discipline where you build software in such a way that it can be released in production at any time.
 
CD best practices:
* version code and configuration
* version environment
* build binaries once
* automate everthing
* smoke test deployments
* deploy to all environments the same way
* create disposable environments
 
Amazon take on Continuous Delivery: https://aws.amazon.com/devops/continuous-delivery/
 
==Continuous Delivery Pipeline==
 
A ''continuous delivery pipeline'' is the automated expression of the process for getting software from version control through building, testing and deployment to the end users, in production.
 
Every change to the software being built, committed in source control, goest through a complex process on its way of being released. This process involves building the software in a reliable and repeatable manner, as well as progressing the built software (called the "build") through multiple stages of testing and deployment.
 
One tool that provides continuous delivery pipeline functionality is [[Jenkins_Concepts#Pipeline|Jenkins]]. Another is [[AWS_CodePipeline_Concepts#Pipeline|AWS CodePipeline]].
 
==Deployment Pipeline==
 
Commit, Acceptance, UAT, Production.
 
=Blue/Green Deployment=
 
{{Internal|Blue-Green Deployment|Blue-Green Deployment}}


=A/B Deployments=
=A/B Deployments=
Line 110: Line 18:


=Semantic Versioning=
=Semantic Versioning=
 
{{Internal|Semantic Versioning|Semantic Versioning}}
{{External|https://semver.org}}
{{External|https://www.infoq.com/news/2017/11/new-version-scheme-java}}


=Good Reads=
=Good Reads=
Line 133: Line 39:


{{Internal|Code Review|Code Review}}
{{Internal|Code Review|Code Review}}
=Software Engineering=
Issues software engineering is concerned with (according to [https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844/ref=sr_1_2?ie=UTF8&qid=1533440533&sr=8-2 CLRS]):
* data abstraction
* modularity
* error handling
=Techical Debt=
* https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473


=Simplicity=
=Simplicity=
Line 153: Line 48:


* https://medium.com/@aevitas/the-tax-you-are-paying-for-using-scrum-50f12298b422
* 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=
=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?"
* 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

Retrieved from "https://kb.novaordis.com/index.php?title=Software_Development&oldid=97152"