q2K BHP
Black History Portal
THE BHP WIRE —
HIDDEN TRUTHS
What's New!
THE JOURNEY THROUGH TIME

Explore Black History

Explore the people, places, events, achievements, struggles and stories that shaped our journey.

✊🏾

Civil Rights

Movements, leaders, victories and the continuing fight for equality.

⚙️

Black Inventors

Innovation, patents, science, technology and world-changing contributions.

🏆

Sports

Pioneers, champions, Negro Leagues, records, activism and excellence.

♟️

People

Meet the people whose lives, choices and achievements shaped the journey.

📍

Places

Black towns, communities, institutions and places where history happened.

📜

Events

Moments that changed communities, movements, institutions and the nation.

Enter a person, place, event, or topic.
MY'STORY

The MOVE Fire

This is a personal recollection on the Move fire on May 13, 1985 Philadelphia police fired thousands of rounds at the MOVE house, city officials approved dropping an explosive device on the roof, the resulting fire was allowed to burn, 11 people—including five children—died, and 61 homes were destroyed. Philadelphia City Council later called it a “brutal attack carried out by the City of Philadelphia on its own citizens” and acknowledged that no individual faced criminal consequences for the bombing. One timeline correction worth preserving for the BHP record: the major previous MOVE-police confrontation was August 8, 1978, about seven years before the bombing, not a year or two earlier. Officer James Ramp was killed, other police and firefighters were wounded, nine MOVE members were later convicted, and television cameras recorded police beating Delbert Africa during his arrest. The 1985 MOVE Commission later specifically criticized city planners for failing to adequately use lessons from that 1978 confrontation. And that actually strengthens the point you’re making: 1985 did not happen without precedent or institutional memory. There had already been a deadly confrontation with MOVE, years of conflict, negotiations and police involvement before Osage Avenue.

MORE →
BLACK FACTS
The Truths They Never Taught You...

Ruler of the Mali Empire in the 14th century

Mansa Musa was the ruler of the Mali Empire in West Africa. Details recorded here should be sourced; unknown information is left blank.

MORE →
BHP gathered finds from its connected research sources. Showing the 4 strongest Black History matches.
← BACK TO RESULTS
Wikipedia

Continuous delivery

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1][2] It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time,[3] and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Principles

[edit]

According to Neal Ford, continuous delivery adopts "Bring the pain forward," tackling tough tasks early, fostering automation and swift issue detection.[4]

Continuous delivery treats the commonplace notion of a deployment pipeline[5] as a lean Poka-Yoke:[6] a set of validations through which a piece of software must pass on its way to release. Code is compiled if necessary and then packaged by a build server every time a change is committed to a source control repository, then tested by a number of different techniques (possibly including manual testing) before it can be marked as releasable.

Developers used to a long cycle time may need to change their mindset when working in a CD environment. Any code commit may be released to customers at any point. Patterns such as feature toggles can be very useful for committing code early which is not yet ready for use by end users.[7] Using NoSQL can eliminate the step of data migrations and schema changes, often manual steps or exceptions to a continuous delivery workflow.[8] Other useful techniques for developing code in isolation such as code branching are not obsolete in a CD world, but must be adapted to fit the principles of CD - for example, running multiple long-lived code branches can prove impractical, as a releasable artifact must be built early in the CD process from a single code branch if it is to pass through all phases of the pipeline.[clarification needed]

Deployment pipeline

[edit]

Continuous delivery is enabled through the deployment pipeline. The purpose of the deployment pipeline has three components: visibility, feedback, and continually deploy.[9]

  • Visibility – All aspects of the delivery system including building, deploying, testing, and releasing are visible to every member of the team to promote collaboration.
  • Feedback – Team members learn of problems as soon as possible when they occur so that they are able to fix them as quickly as possible.
  • Continually deploy – Through a fully automated process, you can deploy and release any version of the software to any environment.


According to Yan Cui, when it comes to serverless environments, ephemeral resources should be kept together and have their own deployment pipeline to achieve a high cohesion. However, shared resources that have a long spin-up time and landing zone should have their own separate repository, deployment pipeline and stack.[10]

Tools/tool types

[edit]

Continuous delivery takes automation from source control all the way through production. There are various tools that help accomplish all or part of this process.[11] These tools are part of the deployment pipeline which includes continuous delivery. The types of tools that execute various parts of the process include: continuous integration, application release automation, build automation, application lifecycle management.[12]

Architecting for continuous delivery

[edit]

To practice continuous delivery effectively, software applications have to meet a set of architecturally significant requirements (ASRs) such as deployability, modifiability, and testability.[13] These ASRs require a high priority and cannot be traded off lightly.

Microservices are often used when architecting for continuous delivery.[14] The use of Microservices can increase a software system's deployability and modifiability. The observed deployability improvements include: deployment independence, shorter deployment time, simpler deployment procedures, and zero downtime deployment. The observed modifiability improvements include: shorter cycle time for small incremental functional changes, easier technology selection changes, incremental quality attribute changes, and easier language and library upgrades.[14]

Implementation and usage

[edit]

The original Continuous delivery book written by Jez Humble and David Farley (2010) popularized the term; however, since its creation the definition has continued to advance and now has a more developed meaning. Companies today are implementing these continuous delivery principles and best practices. The difference in domains, e.g. medical vs. web, is still significant and affects the implementation and usage.[15] Well-known companies that have this approach include Yahoo!,[16] Amazon,[17] Facebook,[18] Google,[19] Paddy Power[1] and Wells Fargo.[20]

Benefits and obstacles

[edit]

Several benefits of continuous delivery have been reported.[1][15]

  • Accelerated time to market: Continuous delivery lets an organization deliver the business value inherent in new software releases to customers more quickly. This capability helps the company stay a step ahead of the competition.
  • Building the right product: Frequent releases let the application development teams obtain user feedback more quickly. This lets them work on only the useful features. If they find that a feature isn't useful, they spend no further effort on it. This helps them build the right product.
  • Improved productivity and efficiency: Significant time savings for developers, testers, operations engineers, etc. through automation.
  • Reliable releases: The risks associated with a release have significantly decreased, and the release process has become more reliable. With continuous delivery, the deployment process and scripts are tested repeatedly before deployment to production. So, most errors in the deployment process and scripts have already been discovered. With more frequent releases, the number of code changes in each release decreases. This makes finding and fixing any problems that do occur easier, reducing the time in which they have an impact.
  • Improved product quality: The number of open bugs and production incidents has decreased significantly.
  • Improved customer satisfaction: A higher level of customer satisfaction is achieved.

Obstacles have also been investigated.[15]

  • Customer preferences: Some customers do not want frequent updates to their systems.
  • Domain restrictions: In some domains, such as telecom, medical, avionics, railway and heavy industries, regulations require customer-side or even on-site testing of new versions.
  • Lack of test automation: Lack of test automation leads to a lack of developer confidence and can prevent using continuous delivery.
  • Differences in environments: Different environments used in the development, testing and production can result in undetected issues slipping to the production environment.
  • Tests needing a human oracle: Not all quality attributes can be verified with automation. These attributes require humans in the loop, slowing down the delivery pipeline.

Eight further adoption challenges were raised and elaborated on by Chen.[21] These challenges are in the areas of organizational structure, processes, tools, infrastructure, legacy systems, architecting for continuous delivery, continuous testing of non-functional requirements, and test execution optimization.

Strategies to overcome adoption challenges

[edit]

Several strategies to overcome continuous delivery adoption challenges have been reported.[21]

Strategies to Overcome CD Adoption Challenges
StrategyDescription
Selling CD as a painkillerIdentify each stakeholder's pain points that CD can solve, and sell CD as a painkiller to that stakeholder. This strategy helps to achieve buy-in from the wide range of stakeholders that a CD implementation requires.
Dedicated team with multi-disciplinary membersWithout a dedicated team, it can be hard to progress because employees are often assigned to work on other value streams. A multi-disciplinary team not only provides the wide range of skills required for CD implementation but also smooths the communication with related teams.
Continuous delivery of continuous deliveryOrganize the implementation of CD in a way that delivers value to the company as early as possible, onboarding more projects gradually, in small increments and eventually rolling out CD across the whole organization. This strategy helps justify the investment required by making concrete benefits visible along the way. Visible benefits, in turn, help to achieve the sustained company support and investment required to survive the long and tough journey to CD.
Starting with easy but important applicationsWhen selecting the first few applications to migrate to CD, choose the ones that are easy to migrate but that are important to the business. Being easy to migrate helps to demonstrate the benefits of CD quickly, which can prevent the implementation initiative from being killed. Being important to the business helps to secure the required resources, demonstrates clear and unarguable value, and raises the visibility of CD in the organization.
Visual CD pipeline skeletonGive a team a visual CD pipeline skeleton that has the full CD pipeline view but with empty stages for those they cannot implement yet. This helps to build up a CD mindset and maintain the momentum for CD adoption. The pipeline skeleton is especially useful when the team's migration to CD requires a large effort and mindset changes over a long period of time.
Expert dropAssign a CD expert to join tough projects as a senior member of the development team. Having the expert on the team helps to build the motivation and momentum to move to CD from inside the team. It also helps to maintain momentum when the migration requires a large effort and a long period of time.

Best practices for cloud systems

[edit]

The following practices can enhance productivity of pipelines, especially in systems hosted in the cloud:[22][23][24]

  • Number of Pipelines: Small teams can be more productive by having one repository and one pipeline. In contrast, larger organizations may have separate repositories and pipelines for each team or even separate repositories and pipelines for each service within a team.
  • Permissions: In the context of pipeline-related permissions, adhering to the principle of least privilege can be challenging due to the dynamic nature of architecture. Administrators may opt for more permissive permissions while implementing compensating security controls to minimize the blast radius.

Relationship to DevOps

[edit]

DevOps is a software engineering approach that centers around cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery.[25][26][27]

Relationship to Continuous Deployment

[edit]

Continuous deployment is a software engineering approach which uses automated software deployments.[21] In it, software is produced in short cycles but through automated software deployments even to production rather than requiring a "click of a button" for that last step.[1]: 52  Therefore, continuous deployment can be considered a more sophisticated form of automation.[28] Academic literature differentiates between continuous delivery and continuous deployment according to deployment method; manual vs. automated.[2][29]

See also

[edit]

Further reading

[edit]

References

[edit]
  1. 1 2 3 4 Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. Bibcode:2015ISoft..32b..50C. doi:10.1109/MS.2015.27. S2CID 1241241.
  2. 1 2 Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices". IEEE Access. 5: 3909–3943. arXiv:1703.07019. Bibcode:2017arXiv170307019S. doi:10.1109/ACCESS.2017.2685629. S2CID 11638909.
  3. ↑ Juha Itkonen and R. Udd and C. Lassenius and Timo Lehtonen (2016). "Perceived Benefits of Adopting Continuous Delivery Practices". Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. doi:10.1145/2961111.2962627.
  4. ↑ Ford, Neal; Parsons, Rebecca; Kua, Patrick; Sadalage, Pramod J. (2022). Building Evolutionary Architectures: Automated Software Governance. O'Reilly Media, Incorporated. ISBN 978-1492097549.
  5. ↑ Humble, J.; Read, C.; North, D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). pp. 113–118. doi:10.1109/AGILE.2006.53. ISBN 0-7695-2562-8. S2CID 16572138.
  6. ↑ Fitzgerald, Brian (2014-06-03). Continuous Software Engineering and Beyond: Trends and Challenges (PDF). 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. pp. 1–9. doi:10.1145/2593812.2593813. hdl:10344/3896. ISBN 978-1-4503-2856-2. Archived from the original (PDF) on 2014-10-25. Retrieved 2014-10-24.
  7. ↑ Rahman, Md Tajmilur; Querel, Louis-Philippe; Rigby, Peter C.; Adams, Bram (2016). "Feature toggles: Practitioner practices and a case study". Proceedings of the 13th International Conference on Mining Software Repositories. pp. 201–211. doi:10.1145/2901739.2901745. ISBN 978-1-4503-4186-8.
  8. ↑ Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. Retrieved 3 January 2014.
  9. ↑ Duvall, Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" (PDF). Refcardz. Archived from the original (PDF) on June 19, 2018. Retrieved October 9, 2015.
  10. ↑ Cui, Yan (2020). Serverless Architectures on AWS (2nd ed.). Manning. ISBN 978-1617295423.
  11. ↑ Phillips, Andrew (29 July 2014). "The Continuous Delivery Pipeline – What it is and Why it's so important in Developing Software". DevOps.com. Archived from the original on 28 September 2015. Retrieved October 9, 2015.
  12. ↑ Binstock, Andrew (16 September 2014). "Continuous Delivery: The Agile SUccessor". Dr. Dobb's the World of Software Development. San Francisco: UBM.
  13. ↑ Chen, Lianping (2015). Towards Architecting for Continuous Delivery. The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015). Montréal, Canada: IEEE. doi:10.1109/WICSA.2015.23. Archived 2018-11-13 at the Wayback Machine
  14. 1 2 Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  15. 1 2 3 Leppänen, M.; Mäkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mäntylä, M. V.; Männistö, T. (2015-03-01). "The Highways and Country Roads to Continuous Deployment". IEEE Software. 32 (2): 64–72. Bibcode:2015ISoft..32b..64L. doi:10.1109/MS.2015.50. ISSN 0740-7459. S2CID 18719684.
  16. ↑ "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 October 2013.
  17. ↑ "Velocity 2011: Jon Jenkins, "Velocity Culture"". youtube.com. 20 June 2011.
  18. ↑ "Rapid Release At Massive Scale". 2017-08-31.
  19. ↑ Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. Retrieved 16 July 2014.
  20. ↑ jFrog (December 2014). "2014-year-continuous-integration-revolution". Managing your binaries.
  21. 1 2 3 Chen, Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. 128: 72–86. doi:10.1016/j.jss.2017.02.013.
  22. ↑ Serverless Architectures on AWS. Manning. 29 March 2022. ISBN 978-1617295423.
  23. ↑ Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform. Manning. 23 November 2021. ISBN 9781638350378.
  24. ↑ Humble, Jez; Farley, David (27 July 2010). Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation. Pearson Education. ISBN 9780321670229.
  25. ↑ Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN 978-0-321-60191-9.
  26. ↑ Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester.
  27. ↑ Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
  28. ↑ "Continuous Deployment: An Essential Guide". IBM. 2019-10-02. Retrieved 2022-11-28. Continuous deployment is the natural outcome of continuous delivery done well. Eventually, the manual approval delivers little or no value and is merely slowly things down. At that point, it is done away with and continuous delivery becomes continuous deployment.
  29. ↑ Shahin, Mojtaba; Babar, Muhammad Ali; Zahedi, Mansooreh; Zhu, Liming (2017). "Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges". 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). pp. 111–120. doi:10.1109/ESEM.2017.18. ISBN 978-1-5090-4039-1. S2CID 3479812.
[edit]

Source: Wikipedia. Article content is retrieved live through the MediaWiki API.

No preview image
Wikipedia

Continuous delivery

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

MORE →
No preview image
Wikipedia

Go continuous delivery

GoCD is an open-source tool which is used in software development to help teams and organizations automate the continuous delivery (CD) of software. It supports automating the entire build-test-release process from code check-in to deployment. It helps to keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. It supports several version control tools including Git, Mercurial, Subversion, Perforce and TFVC (a la TFS). Other version control software can be supported by installing additional plugins. GoCD is released under the Apache 2 License.

MORE →
No preview image
Wikipedia

Continuous deployment

Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently and through automated deployments. Continuous deployment contrasts with continuous delivery (also abbreviated CD), a similar approach in which software functionalities are also frequently delivered and deemed to be potentially capable of being deployed, but are actually not deployed. As such, continuous deployment can be viewed as a more complete form of automation than continuous delivery. Continuous deployment has been adopted by software companies such as Meta, Microsoft, Atlassian, IBM, Adobe, and Tesla.

MORE →
Wikipedia

Content marketing

Content marketing is a form of marketing focused on creating, publishing, and distributing content for a targeted audience online. It is often used to achieve the following business goals: attract attention and generate leads, expand their customer base, generate or increase online sales, increase brand awareness or credibility, and engage a community of online users. Content marketing attracts new customers by creating and sharing valuable free content as well as by helping companies create sustainable brand loyalty, providing valuable information to consumers, and creating a willingness to purchase products from the company in the future. Content marketing starts with identifying the customer's needs. After that, the information can be presented in a variety of long form and short form formats, including news, video, white papers, e-books, infographics, email newsletters, case studies, podcasts, how-to guides, question and answer articles, photos, blogs, etc. Examples of short form content include short blog posts and social media posts. Content marketing requires continuous delivery of large amounts of content, preferably within a content marketing strategy.

MORE →
TOPIC OF THE DAY

Greenwood / Black Wall Street

Before the 1921 destruction of Tulsa’s Greenwood District, Black residents had created a remarkable center of business and community life. The district included stores, professional offices, entertainment venues and homes owned by Black citizens. Understanding Greenwood means learning what was built—not only what was burned.

MORE →
TRIVIA QUESTION OF THE DAY

Which Black woman became the first elected to the United States Congress?

Shirley Chisholm, elected in 1968.