China
Africa
Explore chapters and articles related to this topic
Cloud DevOps
Published in Haishi Bai, Zen of Cloud, 2019
Continuous integration (CI), continuous delivery, and continuous deployment are related terms. Continuous integration is a software development process in which a new build and automated unit tests are automatically triggered whenever a developer checks in new code. This practice enables bugs to be discovered early. In some systems, a code check-in is allowed only when automated tests are passed—this is called gated check-in. Continuous delivery pushes the process further by adding automated integration tests and acceptance tests to ensure the software package remains at a production-ready quality all the time. Finally, continuous deployment automates the last step—deploy to production. With continuous deployment, every code check-in automatically goes through the entire pipeline and ends up in production. Having new versions automatically pushed to production may sound dangerous. However, statistics have shown that most deployment problems are caused by human factors. Eliminating human factors allows more frequent and more reliable deployments, which drastically shortens the customer feedback loop because customers always have access to the latest version.
New Artificial Intelligence Frontiers for Autonomous Networks
Published in Mazin Gilbert, Artificial Intelligence for Autonomous Networks, 2018
Any software delivery system that is looking to optimize speed of innovations must be based on continuous integration and continuous delivery (CI/CD). Continuous integration is a software development technique where small updates to a code tree are added often, making detection and remediation of errors easier to correct. The purpose of a CI environment is to get fast understanding of working code and simplify the debugging process, especially between different development teams. Continuous integration software tools automate the software documentation process and continually test code in a similar fashion. “Continuous” can mean daily for some teams, or hourly, depending on the code and the teams involved. Continuous integration also allows project managers to have a better idea of code completion progress, since commits and testing occurs so rapidly.
You Can’t Waste Money on a Defect That Isn’t There
Published in Matthew Heusser, Govind Kulkarni, How to Reduce the Cost of Software Testing, 2018
Continuous integration, or CI, refers to a development practice in which all new code committed to a source code repository, typically a version control system, is immediately built and deployed to a server where the new features and functionalities are tested right away [4]. When combined with TDD, a direct result of this practice is the confidence it offers developers to commit even major changes to an application. This is because running all unit tests against each new build will immediately reveal if the recent changes broke anything. This also allows doing a quick rollback if necessary. Obviously, the single biggest advantage of CI is instant feedback.
The Virtual Test Bed (VTB) Repository: A Library of Reference Reactor Models Using NEAMS Tools
Published in Nuclear Science and Engineering, 2023
Guillaume L. Giudicelli, Abdalla Abou-Jaoude, April J. Novak, Ahmed Abdelhameed, Paolo Balestra, Lise Charlot, Jun Fang, Bo Feng, Thomas Folk, Ramiro Freile, Thomas Freyman, Derek Gaston, Logan Harbour, Thanh Hua, Wen Jiang, Nicolas Martin, Yinbin Miao, Jason Miller, Isaac Naupa, Dan O’Grady, David Reger, Emily Shemon, Nicolas Stauff, Mauricio Tano, Stefano Terlizzi, Samuel Walker, Cody Permann
To perform continuous integration on the VTB side, multiple applications are checked out side by side with the main repository. The applications within their own repositories are built as though they are being tested in a standalone mode. However, instead of running the normal suite of tests within the application’s repository, the MOOSE “TestHarness” is directed to search for tests in the root of the VTB via the --test-root option. To prevent applications from attempting to run input files found within the VTB tree that were not intended for that application, the executable_pattern key is used within every relevant test specification to match only specific applications. These patterns support full Python regular expression syntax, enabling them to match one or more application patterns. The following example would run only when the SAM or BlueCRAB (Ref. 20) binaries were being used as the executable: executable_pattern = ‘sam*|blue_crab*’.
DevOps adoption: Insights from a large European Telco
Published in Cogent Engineering, 2022
António Trigo, João Varajão, Leandro Sousa
Regarding status quo (Q1), it was possible to verify, by direct observation, that some of the DevOps practices, processes, and tools already existed in the company before the DevOps adoption, which was also later confirmed by the interviewees. The company used continuous integration and continuous delivery practices, but not in the form of an automated pipeline. Planning and automated testing processes were also in use. Concerning DevOps tools, the use of a central code repository, a compilation orchestrator, and deploy and monitoring tools were identified. One example is the use of Jenkins orchestrator for automation processes of some compilations and product installation. To sum up, before DevOps, the company already had some of the required practices, processes and tools, but was experiencing significant communication problems with both Devs and Ops teams. There were also opportunities for improvement by adopting new good practices.
Building optimization testing framework (BOPTEST) for simulation-based benchmarking of control strategies in buildings
Published in Journal of Building Performance Simulation, 2021
David Blum, Javier Arroyo, Sen Huang, Ján Drgoňa, Filip Jorissen, Harald Taxt Walnum, Yan Chen, Kyle Benne, Draguna Vrabie, Michael Wetter, Lieve Helsen
Once the Modelica model, kpis.json, days.json, config.json, and boundary condition data are created, parser.py can be used to compile the Modelica model into the wrapped FMU and move the kpis.json, days.json, config.json, and specified boundary condition .csv files into the ‘resources’ directory of the FMU. This completes the packaging of a test case FMU. Each test case FMU is accompanied by documentation in the form of a .html file describing the building and HVAC system design, baseline control implementation, additional relevant system design, input and output points list and meta-data, important modelling assumptions, and information about sources of energy pricing and CO emission factors. A template has been developed and is utilized by all test case developers for consistency across test cases. Finally, the test cases are collected in a test case repository, where they are available for users and also subject to continuous integration testing. The emulator models are provided in the repository along with specifications of the dependent Modelica library versions as corresponding GitHub commits so that test case versions can be properly defined and maintained.