Literatura académica sobre el tema "Continuous integration and development"

Crea una cita precisa en los estilos APA, MLA, Chicago, Harvard y otros

Elija tipo de fuente:

Consulte las listas temáticas de artículos, libros, tesis, actas de conferencias y otras fuentes académicas sobre el tema "Continuous integration and development".

Junto a cada fuente en la lista de referencias hay un botón "Agregar a la bibliografía". Pulsa este botón, y generaremos automáticamente la referencia bibliográfica para la obra elegida en el estilo de cita que necesites: APA, MLA, Harvard, Vancouver, Chicago, etc.

También puede descargar el texto completo de la publicación académica en formato pdf y leer en línea su resumen siempre que esté disponible en los metadatos.

Artículos de revistas sobre el tema "Continuous integration and development"

1

Vucnik, Matevz, Tomaz Solc, Urban Gregorc, Andrej Hrovat, Klemen Bregar, Miha Smolnikar, Mihael Mohorcic y Carolina Fortuna. "Continuous Integration in Wireless Technology Development". IEEE Communications Magazine 56, n.º 12 (diciembre de 2018): 74–81. http://dx.doi.org/10.1109/mcom.2018.1800107.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

DHANY, AKBAR. "Implementation of Docker and Continuous Integration / Continuous Delivery for Management Information System Development". IJEEIT International Journal of Electrical Engineering and Information Technology 3, n.º 2 (28 de enero de 2021): 20–24. http://dx.doi.org/10.29138/ijeeit.v3i2.1208.

Texto completo
Resumen
A series of Development and Operations (DevOps) in the process of making the Narotama University Management Information System have not been implemented properly by previous developers. There are improvements or additional features of the Management Information System that are in accordance with the functionality and the increasing development needs that will be used by the academic community, so that the Management Information System developer has a little difficulty in integrating documents and distributing applications with different packages to the Production Server. In this study, a new system design is proposed by applying the practice of Continuous Integration / Continuous Delivery as a document integration process and can simplify the application distribution process, as well as implementing the Docker Container Platform as an application container with different packages that can be run on production server together. The results of implementing the practice of Continuous Integration / Continuous Delivery and the implementation of the Docker Container Platform are able to help integrate documents between developers and be able to release fixes and add features packaged in different containers automatically and periodically without long delays. which only takes an average of 17.9 seconds in the process of sending the application to the Production Server.
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

T M, Suhas y Sowmya Nag K. "Continuous Integration and Continuous Deployment with Jenkins in C++ Software Development". Journal of University of Shanghai for Science and Technology 23, n.º 07 (16 de julio de 2021): 805–10. http://dx.doi.org/10.51201/jusst/21/05307.

Texto completo
Resumen
Continuous Integration is a practice in the software program development process where software program builders combine code into a shared repository frequently, more than one instance throughout the day. Jenkins is a continuous integration tool that assists developers and testers by using automating the entire test, on the way to reduce their work with the aid of tracking the development at each and every stage in software development, each integration push is then tested by means of automated build and test cases, and an easy way to make CI quicker and accelerate CI procedure is to automate the testing of a recent build. In this paper, a real scenario is taken into consideration, how the software program trying out is performed in corporate sectors and how Jenkins can save developers/testers important valuable hours by automating the whole software development system.
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Richenhagen, Johannes, Axel Schlosser y Stefan Pischinger. "Development of modular powertrain controls with continuous integration". ATZelektronik worldwide 8, n.º 2 (marzo de 2013): 50–53. http://dx.doi.org/10.1365/s38314-013-0162-1.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

S.K, Arpita, Amrathesh Amrathesh y Dr Govinda Raju M. "A review on Continuous Integration, Delivery and Deployment using Jenkins". Journal of University of Shanghai for Science and Technology 23, n.º 06 (18 de junio de 2021): 919–22. http://dx.doi.org/10.51201/jusst/21/05376.

Texto completo
Resumen
Continuous Integration (CI) is the technique of integrating small changes made to the code more often rather than waiting till the end of the development cycle for integration. The software practice wherein the software deployment can be done anytime to the market is called Continuous Delivery (CD). With continuous integration and continuous delivery, the problem of taking time to find and resolve the bug can be reduced to a large extent. As the time to find the bugs and fix them gets reduced, many releases adhering to the given timeline can be made by an organization. Various software tools have been developed for the continuous integration process which includes Jenkins, Bitbucket, TeamCity. In this paper, a review on the standard practices, approaches, challenges faced while using the continuous integration/delivery in the software development, methods of solving them, and using Jenkins for the implantation of continuous integration/delivery is done.
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Di Benedetto, Vito, Vladimir Podstavkov, Michele Fattoruso y Bruno Coimbra. "Continuous Integration service at Fermilab". EPJ Web of Conferences 214 (2019): 05009. http://dx.doi.org/10.1051/epjconf/201921405009.

Texto completo
Resumen
This paper describes the current architecture of Continuous Integration (CI) service developed at Fermilab, encountered successes and difficulties, as well as future development plans. The current experiment code has hundreds of contributors that provide new features, bug fixes, and other improvements. Version control systems help developers to collaborate in contributing software for their experiments, while the CI system helps developers keep their code healthy. The Fermilab CI service allows experiments and projects to test and validate their offline production and analysis code on the supported platforms. It is built on top of Jenkins, designed to be set up from a configuration file that provides implementation for each phase of the CI workflow, and able to validate experiment code through grid jobs. This CI service provides a dashboard for easy access to logs and statistical graphs. Since the CI service has been adopted by Fermilab experiments/projects, it proved to be very useful to intercept issues in their code early on and get them fixed before running it in production. Currently the CI service is in use by the ArgoNeuT, DUNE, g-2, LArIAT, MINERvA, mu2e, NOvA, SBND and uBooNE experiments and by the following projects: ART and LArSoft software suites, GENIE, and Glidein-WMS. The CI service is under active development and planning to support code profiling.
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Ståhl, Daniel y Jan Bosch. "Modeling continuous integration practice differences in industry software development". Journal of Systems and Software 87 (enero de 2014): 48–59. http://dx.doi.org/10.1016/j.jss.2013.08.032.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

Fahad Ahmad, Sheikh, Mohd Haleem y Mohd Rizwan Beg,. "Test Driven Development with Continuous Integration: A Literature Review". International Journal of Computer Applications Technology and Research 2, n.º 3 (10 de mayo de 2013): 281–85. http://dx.doi.org/10.7753/ijcatr0203.1013.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

Elmsheuser, J., A. Krasznahorkay, E. Obreshkov y A. Undrus. "A Roadmap to Continuous Integration for ATLAS Software Development". Journal of Physics: Conference Series 898 (octubre de 2017): 072009. http://dx.doi.org/10.1088/1742-6596/898/7/072009.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Meis, Jan Fabian y Gunther Reinhart. "Continuous Production Requirements Management". Applied Mechanics and Materials 794 (octubre de 2015): 500–506. http://dx.doi.org/10.4028/www.scientific.net/amm.794.500.

Texto completo
Resumen
Concurrent Engineering has been accepted as an integrated development concept offering significant benefits regarding to cost and development time. Despite of this agreement and the fact that shortened product lifecycles increase the necessity for stronger interaction between all stakeholders involved in product development, benefits are not achieved to the predicted extend. While reasons are manifold, a lack in structured and efficient communication between different departments can be identified as a key obstacle. Recent research activities had addressed requirements management processes outside the limited domain of software and product development and allowed for an integration of production requirements. This paper presents an approach which allows for a continuous requirements process within the production departments. Thus ensuring the integration of up-to-date requirements in all development activities.
Los estilos APA, Harvard, Vancouver, ISO, etc.
Más fuentes

Tesis sobre el tema "Continuous integration and development"

1

Amaradri, Anand Srivatsav y Swetha Bindu Nutalapati. "Continuous Integration, Deployment and Testing in DevOps Environment". Thesis, Blekinge Tekniska Högskola, Institutionen för programvaruteknik, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-13334.

Texto completo
Resumen
Context. Owing to a multitude of factors like rapid changes in technology, market needs, and business competitiveness, software companies these days are facing pressure to deliver software rapidly and on a frequent basis. For frequent and faster delivery, companies should be lean and agile in all phases of the software development life cycle. An approach called DevOps, which is based on agile principles has come into play. DevOps bridges the gap between development and operations teams and facilitates faster product delivery. The DevOps phenomenon has gained a wide popularity in the past few years, and several companies are adopting DevOps to leverage its perceived benefits. However, the organizations may face several challenges while adopting DevOps. There is a need to obtain a clear understanding of how DevOps functions in an organization. Objectives. The main aim of this study is to provide a clear understanding about how DevOps works in an organization to researchers and software practitioners. The objectives of the study are to identify the benefits of implementing DevOps in organizations where agile development is in practice, the challenges faced by organizations during DevOps adoption, to identify the solutions/ mitigation strategies, to overcome the challenges,the DevOps practices, and the problems faced by DevOps teams during continuous integration, deployment and testing. Methods. A mixed methods approach having both qualitative and quantitative research methods is used to accomplish the research objectives.A Systematic Literature Review is conducted to identify the benefits and challenges of DevOps adoption, and the DevOps practices. Interviews are conducted to further validate the SLR findings, and identify the solutions to overcome DevOps adoption challenges, and the DevOps practices. The SLR and interview results are mapped, and a survey questionnaire is designed.The survey is conducted to validate the qualitative data, and to identify the other benefits and challenges of DevOps adoption, solutions to overcome the challenges, DevOps practices, and the problems faced by DevOps teams during continuous integration, deployment and testing. Results. 31 primary studies relevant to the research are identified for conducting the SLR. After analysing the primary studies, an initial list of the benefits and challenges of DevOps adoption, and the DevOps practices is obtained. Based on the SLR findings, a semi-structured interview questionnaire is designed, and interviews are conducted. The interview data is thematically coded, and a list of the benefits, challenges of DevOps adoption and solutions to overcome them, DevOps practices, and problems faced by DevOps teams is obtained. The survey responses are statistically analysed, and a final list of the benefits of adopting DevOps, the adoption challenges and solutions to overcome them, DevOps practices and problems faced by DevOps teams is obtained. Conclusions. Using the mixed methods approach, a final list of the benefits of adopting DevOps, DevOps adoption challenges, solutions to overcome the challenges, practices of DevOps, and the problems faced by DevOps teams during continuous integration, deployment and testing is obtained. The list is clearly elucidated in the document. The final list can aid researchers and software practitioners in obtaining a better understanding regarding the functioning and adoption of DevOps. Also, it has been observed that there is a need for more empirical research in this domain.
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

Nilsson, Samuel. "Implementation of a Continuous Integration and Continuous Delivery System for Cross-Platform Mobile Application Development". Thesis, Linköpings universitet, Interaktiva och kognitiva system, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-129922.

Texto completo
Resumen
When working in software development teams, there are challenges when it comes to always keeping the software stable and reliable. Continuous integration are frequently used to increase the stability and reliability. Extensive research has been performed on the matter of development processes of continuous integration, but there are no consensus on how systems to support continuous integration should be implemented for best results. In this report a continuous integration system is implemented based on best practices and to support the general continuous integration development process, by using Jenkins and other open source tools. The system is adapted to work well with the cross-platform mobile development framework CoffeeMaker developed by VISIARC AB and the general needs of the company. In order to roughly estimate the increased developer productivity and product quality when introducing the system, a questionnaire that discusses the system and working habits was sent out to the developers. The evaluation lead to the conclusion that the productivity would improve by approximately 30-60 minutes per week and developer. It also lead to the conclusion that the quality of their developed applications would most probably increase by introducing such a system.
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

Hagsten, Per. "Evaluation of a qualitative model for a company's technical maturity within Continuous Integration, Continuous Delivery and DevOps". Thesis, KTH, Skolan för elektroteknik och datavetenskap (EECS), 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-233554.

Texto completo
Resumen
The purpose of this study is to continue development of a benchmarking model to help companies assess their technical maturity when it comes to adopting Continuous Integration, Continuous Delivery and DevOps in their organization. The goal of the research is to assess how to improve the quality of qualitative models. Which conclusions can be drawn from comparing companies using benchmark and to assess which actions are the most effective to take to reach higher Continuous Integration, Continuous Delivery and DevOps maturity. The benchmark consisted of a questioner of two hundred statements that were answered for level of agreement with a current situation analysis and an ought-to-be analysis to be able to draw conclusions from the possible discrepancy between these categories. The questioner was answered during an interview study with chosen clients. Conclusions drawn from this study were that a lot can be done to improve the quality of qualitative models for examining Continuous Integration, Continuous Delivery and DevOps maturity. Different actions are necessary but the most important seems to be to ask open ended questions as well ass questions about different aspects of the same problem to promote discussion. It was also showed to be important to peer review the questions in the interview material beforehand to increase quality. The study also showed that it is possible to see trends in Continuous Integration, Continuous Delivery and DevOps maturity when comparing qualitative results for research subjects. The study showed that the most effective method for increasing Continuous Integration, Continuous Delivery and DevOps maturity is to use extensive automated testing suites that covers all testing disciplines.
Syftet med studien är att vidareutveckla ett benchmarkingverktyg för att hjälpa företag att bedöma sin tekniska mognad när det gäller att anta Continuous Integration, Continuous Delivery och DevOps i sin organisation. Målet med forskningen är att bedöma hur man kan förbättra kvaliteten på kvalitativa modeller för att mäta detta, samt vilka slutsatser som kan dras av att jämföra företags resultat som nyttjat studien. Samt att undersöka vilka åtgärder som är effektivast att ta för att nå en högre mognadsgrad inom Continuous Integration, Continuous Delivery och DevOps. Benchmarken bestod av ett frågebatteri av tvåhundra påståenden som besvarades av kunden i hur mycket de instämde till ett påstående. Resultatet samanställdes till en aktuell nulägesanalys och en börlägesanalys, med målet att dra slutsatser i vilka skillnaden som fanns mellan dessa två kategorier. Kunden besvarade frågebatteriet under en intervjustudie med utvalda anställda. Slutsatser som härrör från denna studie var att mycket kan göras för att förbättra kvaliteten på kvalitativa modeller för att undersöka Continuous Integration, Continuous Delivery och DevOps mognadsgrad. Olika åtgärder är möjliga, men det viktigaste förefaller vara att fråga öppna frågor för att främja diskussion samt att ställa frågor om olika aspekter av samma problem. Samt att opponera frågorna internt i intervjuundersökningen innan det utförs hos en kund, för att öka kvaliteten. Studien visade också att det även är möjligt att se trender i Continuous Integration, Continuous Delivery och DevOps mognad hos deltagarna när man jämför de kvalitativa resultaten. Studien visade att de mest effektiva metoderna för att öka Continuous Integration, Continuous Delivery och DevOps mognadsgrad är att använda omfattande automatiserade testsviter för samtliga testmetoder.
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Seppänen, V. (Vili). "Enhancing continuous integration processes in agile development using project management tools". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201809062759.

Texto completo
Resumen
This thesis presents a concept to enhance the continuous integration processes in agile development, by utilising the combination of project management tools and user stories. First, the reader is introduced to the fields of continuous integration, agile, feature toggles and version control to provide a good basic understanding of the context. Related work on release engineering is presented from the perspective of release planning and constructing. Problems with current, commonly used continuous integration processes are identified and analysed, and then solutions for these problems are designed and proposed. This includes listing the requirements for implementing the solutions, describing the designs of the solutions and discussing the expected benefits of the solutions. These solutions form the concept to enhance the continuous integration processes in agile development. This new concept is evaluated in a user-study among seasoned IT professionals. The study includes applicable elements from Expectation Disconfirmation Theory to examine the validity and the likely future adoption of the proposed approach in the information technology sector. The evaluation results suggest that the solution, when implemented in a production environment, will be easy to use; have the capability, functions and features needed to accomplish its tasks; will be reliable and beneficial for its purpose and would be likely to improve the overall performance of the software project
Tämä diplomityö esittelee konseptin jatkuvan integraation prosessien tehostamiseen ketterässä ohjelmistokehitysympäristössä. Konsepti perustuu projektinhallintatyökalujen ja käyttäjätarinoiden uudentyyppiseen ja älykkäämpään linkittämiseen. Aluksi työssä esitellään jatkuva integraatio, ketterä ohjelmistokehitys, liput sekä versionhallinta aihealueen perusteiden ymmärtämiseksi. Lisäksi esitellään julkaisunhallinta julkaisusuunnittelun ja julkaisun koostamisen näkökulmasta niiltä osin kuin se on diplomityön kannalta olennaista. Nykyisten yleisesti käytettävien jatkuvan integraation prosessien ongelmat tunnistetaan ja analysoidaan, ja näihin ongelmiin suunnitellaan ja esitetään ratkaisut. Esitellyt ratkaisut sisältävät niiden toteuttamista koskevien vaatimusten luetteloinnin, suunnitellun toteutuksen kuvauksen sekä pohdinnan ratkaisuista odotettavista hyödyistä. Nämä ratkaisut muodostavat konseptin jatkuvan integraation prosessien tehostamiseksi ketterässä ohjelmistokehityksessä. Esitelty uusi konsepti arvioidaan kokeneiden IT-ammattilaisten keskuudessa tehdyn käyttäjätutkimuksen avulla. Käyttäjätutkimuksessa käytetään soveltuvia elementtejä odotusten kumoamisen mallista, minkä avulla tarkastellaan ehdotetun lähestymistavan soveltuvuutta sekä tulevan käyttöönoton todennäköisyyttä tietotekniikka-alalla. Arvioinnin tulokset viittaavat siihen, että tuotantoympäristöön toteutettuna, ratkaisu on helppokäyttöinen, pitää sisällään valmiudet, toiminnallisuuden ja ominaisuudet sille annettujen tehtävien suorittamiseksi, on luotettava ja hyödyllinen, ja parantaa todennäköisesti ohjelmistoprojektin yleistä tehokkuutta
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

Lindström, Gustav. "The Challenges of adopting DevOps". Thesis, KTH, Skolan för industriell teknik och management (ITM), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-264179.

Texto completo
Resumen
In traditional Software Development Life Cycle, medium and large organizations tend to divide the activities of Operations and Development into separate departments. These groups often have a troublesome relationship because of different incentives during the software delivery process. As a result, conflicts occur between development and operations personnel as they blame each other to be the cause of long lead times and inefficient software delivery processes. The concept of DevOps emerged trying to resolve the problem that arises when separating the work of Development and Operations into organizational silos. The term DevOps is a combination of the abbreviations of Development (Dev) and Operations (Ops). DevOps aim to create a coalition that spans between Development (software developers and quality assurance) and Operation (experts responsible to roll out software to production and managing the infrastructure, e.g. system, network and database administrators and technicians). The idea is to increase the speed of the software delivery process and to quickly solve critical issues, enable organizations to better serve their customers. DevOps means that development teams who previously were solely responsible for the development of their applications now have to manage and govern both development and operational responsibilities. Thus, the adoption of DevOps might introduce new type of challenges and implications for the traditional development teams. Current literature and research about DevOps focus mainly on the challenges that DevOps attempts to overcome. There is a lack of literature on the challenges that practitioners encounter during the adoption of DevOps. As more organizations and companies tend to adopt the concept of DevOps, it increases the need to understand potential challenges and effects of adopting DevOps. Therefore, the aim of this study is to investigate the challenges that development teams encounter during the adoption of DevOps. This research was conducted by an inductive research approach through a single qualitative case study, with the use of semi-structured interviews. In total, four main challenges and fourteen sub-challenges were identified in this study. The four main challenges identified was, lack of awareness, lack of support for DevOps, implementing DevOps technology and adapting organizational processes to DevOps. This study concludes that the adoption of DevOps has a profound impact on the role of a software developer, and that the traditional role of a software developer needs to be evolved. The research provides four recommendations and means to overcome the challenges identified in this research, establishing common ways of working and spreading the knowledge, building commitment and trust by smarter seating, allocate time and resources to transition and trying out with one team and one application.
I traditionell livscykel för mjukvaruutveckling tenderar medelstora och stora organisationer att dela upp verksamheten i drift och utveckling i separata avdelningar. Dessa grupper har ofta en besvärlig relation på grund av olika incitament under mjukvaruleveransprocessen. Som ett resultat uppstår konflikter mellan utvecklings- och driftpersonal eftersom de beskyller varandra för att vara orsaken till långa ledtider och ineffektiva mjukvaruleveransprocesser. Konceptet DevOps uppstod för att försöka lösa det problem som uppstår när man separerar utveckling och drift i organisationella silosar. Termen DevOps är en kombination av förkortningarna för utveckling (Dev) och drift (Ops). DevOps syftar till att skapa en koalition som sträcker sig mellan utveckling (mjukvaruutvecklare och kvalitetssäkring) och drift (system-, nätverks- och databasadministratörer och tekniker). Idén är att öka hastigheten av mjukvaruleveranser och att snabbt lösa kritiska problem för att förbättra organisationens förmåga att betjäna sina kunder. DevOps innebär att utvecklingsgrupper som tidigare enbart ansvarade för utvecklingen av sina applikationer nu även har driftansvar. Således kan antagandet av DevOps introducera nya typer av utmaningar och konsekvenser för de traditionella utvecklingsgrupperna. Aktuell litteratur och forskning kring DevOps fokuserar främst på de utmaningar som DevOps försöker övervinna. Därav finns det brist på litteratur kring de utmaningar som utövare stöter på under antagandet av DevOps. Eftersom fler organisationer och företag tenderar att adoptera begreppet DevOps ökar behovet av att förstå potentiella utmaningar och effekter av att anta DevOps. Därav är syftet med denna studie att undersöka de utmaningar som utvecklingsgrupper bemöter under antagandet av DevOps. Denna forskning utfördes genom en induktiv forskningsinriktning, en kvalitativ fallstudie och datainsamling genom halvstrukturerade intervjuer. Totalt identifierades fyra huvudutmaningar och fjorton sub utmaningar i denna studie. De fyra huvudsakliga utmaningar som identifierades var, brist på medvetenhet, brist på stöd för DevOps, implementering av DevOps-teknik och anpassning av organisationsprocesser till DevOps. Den här studien drar slutsatsen att antagandet av DevOps har en djupgående inverkan på rollen som en mjukvaruutvecklare och att den traditionella rollen som en mjukvaruutvecklare behöver utvecklas. Studien ger fyra rekommendationer och medel för att övervinna de utmaningar som identifierats, etablering av gemensamma sätt att arbeta och sprida kunskapen, bygga upp engagemang och förtroende genom smartare sittplatser, fördela tid och resurser till övergången samt prova med ett lag och en applikation.
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Christensen, Jens y Jonatan Ekstedt. "Evaluation of Plugin Frameworks for the Jenkins Continuous Integration Build Server". Thesis, Linköpings universitet, Institutionen för datavetenskap, 2012. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-77181.

Texto completo
Resumen
Begreppet Continuous Integration (CI) är idag centralt för många företag i deras produktutveckling. Kraven dessa företag ställer på denna programvara skiljer sig, beroende på vad de använder den till och hur deras miljö ser ut. Jenkins är en programvara som används för CI, det är öppen källkod och har ett brett stöd för pluginer. Det finns ett stort urval av pluginer redan idag, men det är inte säkert att specifika önskemål från företag uppfylls av dessa. Därför är det intressant att på ett snabbt sätt ta fram specifika pluginer för dessa företag. Vi har i denna rapport utrett möjligheterna att utveckla pluginer till Jenkins i Ruby. Det senaste året har utveckling av pluginer i Ruby vuxit fram för Jenkins. Ramverket är fortfarande i ett tidigt stadium, men är utformat för att kunna falla tillbaka på det programmeringsspråk som Jenkins är skrivet i; Java. Det är på så sätt fullt möjligt att nu skriva pluginer i Ruby. Ruby är ett expressivt språk som är lätt att ta till sig, och den komplexitet som följer pluginutveckling i Java är till stor del gömd i Rubys ramverk. Vår slutsats är att Ruby är tillräckligt moget för att användas till pluginutveckling för Jenkins. Examensarbetet är uppdelat i två delar: en utvärdering av ramverken och deras verktyg för Ruby och Java, och en utvecklingsfas där vi fastställer vår analys. Den Rubyplugin som utvecklats kan ses som ett ‘proof-of-concept’, denna kan även användas som en slags mall vid framtida pluginutveckling vid Autoliv.
The concept Continuous Integration (CI) is vital to many companies today in their product development. These companies may have specific demands on their CI-software, depending on how they are using it and what their development environment looks like. Jenkins is a software that is used for CI, it is open source and it has a wide support for plugins. There is a great selection of plugins available today, but it is not certain these plugins satisfy the specific requirements. It is therefore interesting to, in a quick way, develop plugins that meet these conditions. In this report, we have evaluated the possibility to develop plugins for Jenkins in Ruby. In the last year or so, plugin development in Ruby has been growing to become a viable option. The framework is still at a very early stage, but it is constructed in such a way so that one can always fall back on the language Jenkins was made in;; Java. Because of this it’s definitely possible to write plugins in Ruby. Ruby is an expressive language and it is easy to learn, the complexity that comes with writing plugins in Java for Jenkins is largely hidden in the Ruby framework. Our conclusion is that Ruby is ready to be used for plugin development for Jenkins. This thesis is divided into two parts, an evaluation of the frameworks and the tools for Java and Ruby, and a development phase where we concrete our analysis. The Ruby plugin that is developed in this thesis can be seen as proof-of-concept, it can also be used as a kind of template for future plugin development at Autoliv.
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Gawell, Anders y Anton Kallin. "Teaching software testing in a modern development environment". Thesis, KTH, Skolan för elektroteknik och datavetenskap (EECS), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-261162.

Texto completo
Resumen
All developers understand the benefits of testing their code to ensure its functionality. Today’s market is moving further towards design principles where testing is a central or driving force during development. This puts a certain pressure on academia to supply these skills to their students.Recently the course II1302 Projects and project methods at the Royal Institute of Technology in Kista made a concerted effort to introduce the students of the course to these modern concepts. This thesis investigates how areas of testing can effectively be introduced to the students in the course, utilizing a tailored example that takes the area of testing into particular consideration and how to automate it via DevOps-tools provided by a cloud-based service. Further, it also makes an attempt to provide additional material to be used for teaching testing in conjunction with the example provided.The case study covers the development of an example application, meant to mirror a typical student project. It also covers how this was used for teaching the students about the testing areas considered. The covered testing areas include unit testing, integration testing and UI testing. With these given testing areas, the application and an associated learning module was developed for each area in question. Relevant standards, strategies and approaches was also identified for each of these areas.The thesis also presents important properties to take into consideration when developing similar examples in the future, based on the experiences obtained during the study. These include needs such as understandable by inexperienced students, applicability outside the course, adherence to established standards, tools that are simple to use and an architectural structure that allows for testing.Some improvements are also recommended: the students would benefit from learning software testing from an early stage of their studies. The content of the learning modules should also be brought to the students earlier in the course, so it can be applied in their projects at an early stage as well.Further research is also recommended to evaluate the suitability of using other cloud-based environments instead, and to evaluate the applicability of the learning modules for students of varying disabilities.
Alla utvecklare förstår fördelarna med att testa kod för att garantera dess funktionalitet. Dagens industri går i en riktning där testning spelar en central del av design under utveckling av mjukvara. Denna tendens lägger en viss press på högskolan att lära ut dessa erfarenheter till dess studenter.På senare tid har kursen II1302 Projekt och projektmetoder på Kungliga Tekniska Högskolan i Kista tagit en stor ansats för att introducera sina studenter inför dessa moderna koncept. Denna uppsats undersöker hur testningsområdet effektivt kan introduceras till studenterna inom denna kurs, genom att utnyttja ett egengjort exempel som har området i fokus, samt att automatisera detta via DevOps-verktyg tillhandahållna av molnbaserade tjänster. Dessutom görs även en ansats för att tilldela ytterligare material som kan användas för att lära ut testning av mjukvara i samband med det givna exemplet.Fallstudien omfattar utvecklingen av en exempelapplikation, som var avsedd att likna ett typiskt studentprojekt. Den täcker även hur denna användes för att lära ut de betraktade testningsområdena till studenterna. De täckta områdena av testning inkluderar enhetstestning, integrationstestning och testning av användargränssnitt. Med dessa givna testningsområden utvecklades både applikationen och dess associerade lärmoduler för vardera testningområde i fråga. Relevanta standarder, strategier och metoder var också identifierade för vardera av dessa områden.Denna uppsats presenterar även ett antal viktiga egenskaper att hålla i åtanke vid utveckling av liknande exempel i framtiden, baserat på erfarenheterna från studien. Detta inkluderar behov som tillgänglighet för mindre erfarna studenter, applicerbarhet utanför själva kursen, tillämpning av etablerade standarder, utnyttjande av lättanvända verktyg och en arkitektur som tillåter testning.Några förbättringar föreslås även: studenterna skulle gynnas av att lära sig om mjukvarutestning i ett tidigt skede av sina studier. Innehållet i lärmodulerna bör även presenteras för studenterna tidigare i kursen för att kunna appliceras i deras projekt.Ytterligare forskning rekommenderas även för att utvärdera andra lämpliga molnbaserade miljöer, samt för att utvärdera tillämpbarheten av lärmodulerna hos studenter med inlärningssvårigheter.
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

Salomonsson, Tigerström Andreas y Sebastian Algrim. "Mjukvaruutveckling med Continuous Delivery : En kvalitativ fallstudie om Continuous Practices med fokus på Continuous Delivery". Thesis, Linnéuniversitetet, Institutionen för informatik (IK), 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:lnu:diva-76357.

Texto completo
Resumen
Denna uppsats studerar förutsättningarna för att implementera mjukvaruutvecklings - metoden Continuous Delivery (CDE). Problemställningen som lade grunden för studien, var att det inte finns någon enhetlig standard för CDE. Studien ämnade att undersöka om detta innebar att metoden har varierande innebörd inom olika företag och om de således, i viss mån tillämpar skilda tillvägagångssätt med metoden. Ytterligare en aspekt var att se vilka utmaningar företagen upplevde vid övergången till CDE. Att undersöka om det var främst organisatoriska eller utvecklingsrelaterade problem som upplevts. Samt hur de hanterade kommunikation och tillit till medarbetarna och arbetet inom verksamheten under förändringen. För att belysa problemen, beskrevs teori med fokus på organisatoriska och tekniska utmaningar med Continuous - metoderna: Continuous Integration (CI), Continuous Delivery (CDE) och Continuous Deployment (CD). Teorikapitlet samt tidigare studier inkluderade även forskning om kringliggande koncept som DevOps och LEAN. Metoder, vilka kan underlätta implementationen av CDE. Datainsamlingen genomfördes med öppna individuella intervjuer med representanter från sex stycken företag, där de delade med sig av deras erfarenheter av och syn på CDE. Studien visar att anledningen till att företag väljer att arbeta med CDE, är att de vill gå från utvecklingsmetoder, vilka kräver många beslut inför varje förändring, till ett mer flexibelt arbetssätt där de funnit fördelar som: bättre kvalitet på det som levereras, snabbare leverans av affärsvärde till kunder samt kortare feedback - loopar. Företag som gör en övergång till CDE väljer dessutom ofta att inte automatisera hela vägen ut till produktion, enligt CD, då de ser utmaningar med att säkra kvalitén. Studien har identifierat ett antal faktorer som viktiga för en framgångsrik implementering av CDE, samt faktorer som kan resultera i en svår övergång.
This thesis studies the conditions needed for implementing the software development method Continuous Delivery (CDE). The problem identified for the study, is that there is no standardized approach for CDE as of today. The intentions of the study were to determine whether this means that the method will have a shifting tenor within different companies, and if so, will these companies implement the method with different approaches. Another aspect was to determine which types of challenges the companies were faced with during the transition towards CDE. To review whether the challenges were foremost organisational or development related. And how the organisations handled the communication and trust towards the co-workers and the development work within the organisation during the change towards the method. To highlight these issues, we presented theories with focus on organisational and technical challenges with the different Continuous practices were made. The practices being: Continuous Integration (CI), Continuous Delivery (CDE) and Continuous Deployment (CD). The theory chapter and former studies also contains research about surrounding concepts such as DevOps and LEAN methods, which can aim to facilitate the implementation of CDE. The empirical data collection was performed using open individual interviews with informants from six different companies, where they shared their experience and views on the method CDE. The study demonstrates that the reason organisations chose to implement CDE, is that they want to transform from software development methods, which requires a lot of decision making for any change, to a more flexible work procedure, in order to experience benefits such as: better quality of what is delivered, faster deliveries of business value to the customers and faster feedback-loops. Organisations that make the transition towards CDE also tend not to automate all the way to production, as in agreement with CD, this because the organisations identify challenges with assuring that the quality is sufficient. The study has identified a number of factors that are essential for a successful implementation of CDE, along with factors that may result in a less successful implementation.
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

Karvonen, T. (Teemu). "Continuous software engineering in the development of software-intensive products:towards a reference model for continuous software engineering". Doctoral thesis, Oulun yliopisto, 2017. http://urn.fi/urn:isbn:9789526216560.

Texto completo
Resumen
Abstract Continuous software engineering (CSE) has instigated academic debate regarding the rapid, parallel cycles of releasing software and customer experimentation. This approach, originating from Web 2.0 and the software-as-a-service domain, is widely recognised among software-intensive companies today. Earlier studies have indicated some challenges in the use of CSE, especially in the context of business-to-business and product-oriented, embedded systems development. Consequently, research must address more explicit definitions and theoretical models for analysing the prerequisites and organisational capabilities related to the use of CSE. This dissertation investigates various approaches to conducting empirical evaluations related to CSE. The study aims to improve existing models of CSE and to empirically validate them in the context of software companies. The study also aims to accumulate knowledge regarding the use of CSE, as well as its impacts. The case study method is applied for the collection and analysis of empirical data. Twenty-seven interviews are conducted at five companies. In addition, a systematic literature review is used to synthesise the empirical research on agile release engineering practices. Design science research is used to portray the model design and the evaluation process of this dissertation. Three approaches for evaluating CSE are constructed: (1) LESAT for software focuses on enterprise transformation using an organisational self-assessment approach, (2) STH+ extends the “Stairway to Heaven” model and evaluates company practices with respect to evolutionary steps towards continuous experimentation-driven development, and (3) CRUSOE defines 7 key areas and 14 diagnostic questions related to the product-intensive software development ecosystem, strategy, architecture, and organisation, as well as their continuous interdependencies. This dissertation states the relevance of CSE in the context of product-intensive software development. However, more adaptations are anticipated in practices that involve business and product development stakeholders, as well as company external stakeholders
Tiivistelmä Jatkuva ohjelmistotuotanto on herättänyt keskustelua nopeasta, samanaikaisesta ohjelmistojulkaisemisesta ja asiakaskokeiluista. Toimintatapa on peräisin Web 2.0 ja software-as-a-service yhteydestä, mutta se tunnetaan nykyään yleisesti ohjelmistoja kehittävissä yrityksissä. Aiemmat tutkimukset ovat osoittaneet haasteita jatkuvan ohjelmistotuotannon käytössä. Erityisesti haasteita on havaittu yritykseltä yritykselle liiketoiminnassa ja tuotepainotteisten sulautettujen järjestelmien yhteydessä. Näin ollen on havaittu tarve tutkimuksen avulla kehittää täsmällisempiä määritelmiä ja teoreettisia malleja, joilla voidaan analysoida jatkuvan ohjelmistotuotannon käyttöön liittyviä edellytyksiä ja organisaatioiden kyvykkyyksiä. Tässä väitöskirjassa tutkitaan malleja, joilla voidaan empiirisesti arvioida jatkuvaa ohjelmistotuotantoa. Tutkimuksella pyritään parantamaan nykyisiä malleja ja arvioimaan niiden käyttöä ohjelmistoyrityksissä. Lisäksi tutkimuksella pyritään kasvattamaan tietoa jatkuvasta ohjelmistotuotannosta ja sen vaikutuksista. Tiedon keräämiseen ja analysointiin käytettiin tapaustutkimus menetelmää. Kaksikymmentäseitsemän haastattelua tehtiin viidessä yrityksessä. Lisäksi tehtiin ketterään ohjelmistojulkaisuun keskittyvä systemaattinen kirjallisuuskatsaus. Väitöskirjassa käytetään Design Science Research menetelmää kuvaamaan tutkimuksen eri vaiheita, joissa malleja suunniteltiin ja arvioitiin. Tutkimuksessa rakennettiin kolme tapaa jatkuvan ohjelmistotuotannon arvioimista varten: (1) LESAT for Software keskittyy organisaation muutoskyvykkyyden arviointiin käyttäen itsearviointimenetelmää, (2) STH+, laajentaa ”Stairway to Heaven” mallia ja arvioi yrityksen käytäntöjä eri evoluutioaskelmilla matkalla kohti kokeilupainotteista tuotekehitystä, (3) CRUSOE määrittelee seitsemän pääaluetta ja 14 kysymystä liittyen tuotekehityksen ekosysteemiin, strategiaan, arkkitehtuuriin, organisointiin sekä näiden välisiin jatkuviin riippuvuuksiin. Väitöskirja osoittaa jatkuvan ohjelmistokehityksen olevan merkityksellinen myös tuotepainotteisessa ohjelmistokehityksessä. Nähtävissä kuitenkin on, että useita nykykäytäntöjä on tarvetta muokata. Erityisesti muokkaustarvetta on tuotekehityksen ja liiketoiminnan sidosryhmiin ja yrityksen ulkoisiin sidosryhmiin liittyvissä käytännöissä
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Koivuniemi, J. (Jarmo). "Shortening feedback time in continuous integration environment in large-scale embedded software development with test selection". Master's thesis, University of Oulu, 2017. http://urn.fi/URN:NBN:fi:oulu-201704121470.

Texto completo
Resumen
Continuous integration is one of the Extreme Programming practices and is used in agile software development to provide rapid feedback and to have a working system at all times. In continuous integration, a developer commits code to projects mainline at least once a day which triggers automated build and tests. Large projects can struggle with continuous integration because with growing code base the number of tests that need to execute after a developer checks in code also gets bigger. The growing number of tests means that the build times can become long. With embedded systems, the problem can be even bigger as the testing is dependent on target hardware. With long builds, feedback becomes longer thus making it harder to practice continuous integration. Long feedback leads to infrequent integrations which can result in continuous integration becoming a bottle-neck to the development process and can even affect an ability to release software frequently. To shorten the feedback this thesis implements an automated test selection tool to work in continuous integration environment. The test selection tool selects the tests that are relevant for a specific code change instead of executing all tests for each commit. The case company is suffering from long feedbacks and the expensiveness of testing has become a problem. This thesis hopes to solve that problem with the implemented test selection tool. The tool is evaluated using three metrics; feedback time improvement, reduction in number of executed test cases and fault finding capability. The test selection tool was tested with two test suites with different size by collecting data from continuous integration system. “Shock” suite consisted of about 30 test cases and regression suite about 800 test cases. The average improvement in feedback time for Shock tests was 29.3% and 55.7% for regression suite. The test selection tool reduced the number of test cases executed in Shock by 67.1% and 78.2% for regression suite. Fault finding capability was measured for Shock suite and the tool was able to find same faults as the full suite in 97.8% of the cases. Statistical tests show that the test selection has a significant impact on feedback time. By being able to safely shorten the feedback, the test selection tool can potentially help developers in the case company to practice continuous integration.
Los estilos APA, Harvard, Vancouver, ISO, etc.
Más fuentes

Libros sobre el tema "Continuous integration and development"

1

1966-, Ambler Scott W., ed. Recipies for continuous database integration: Evolutionary database development. Boston, Mass: Addison Wesley Professional, 2007.

Buscar texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

1979-, Matyas Steve y Glover Andrew 1976-, eds. Continuous integration: Improving software quality and reducing risk. Upper Saddle River, NJ: Addison-Wesley, 2007.

Buscar texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

Macharla, Pradeep. Android Continuous Integration. Berkeley, CA: Apress, 2017. http://dx.doi.org/10.1007/978-1-4842-2796-1.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Pouclet, Romain. Pro iOS Continuous Integration. Berkeley, CA: Apress, 2014. http://dx.doi.org/10.1007/978-1-4842-0124-4.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

Lenz, Moritz. Python Continuous Integration and Delivery. Berkeley, CA: Apress, 2019. http://dx.doi.org/10.1007/978-1-4842-4281-0.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Versluis, Gerald. Xamarin Continuous Integration and Delivery. Berkeley, CA: Apress, 2017. http://dx.doi.org/10.1007/978-1-4842-2716-9.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Alan, Winters L., ed. Regional integration and development. Washington, DC: World Bank, 2003.

Buscar texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

László, Csaba. Transformation, development, EU-integration. Frankfurt (Oder): Frankfurter Institut für Transformationsstudien, 2001.

Buscar texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

United Nations. Economic Commission for Latin America and the Caribbean. Globalization and development. [Santiago, Chile]: ECLAC, 2002.

Buscar texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Tondl, Gabriele, ed. Trade, Integration and Economic Development. Vienna: Springer Vienna, 2008. http://dx.doi.org/10.1007/978-3-211-75150-3.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
Más fuentes

Capítulos de libros sobre el tema "Continuous integration and development"

1

Rosenfield Boeira, Julia Naomi. "Continuous Integration". En Lean Game Development, 67–75. Berkeley, CA: Apress, 2017. http://dx.doi.org/10.1007/978-1-4842-3216-3_7.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

Verma, Rishabh. "Continuous Integration and Hosting". En Visual Studio Extensibility Development, 333–74. Berkeley, CA: Apress, 2020. http://dx.doi.org/10.1007/978-1-4842-5853-8_8.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

Crookshanks, Edward. "Build Tools and Continuous Integration". En Practical Software Development Techniques, 65–77. Berkeley, CA: Apress, 2014. http://dx.doi.org/10.1007/978-1-4842-0728-4_4.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Crookshanks, Edward. "Build Tools and Continuous Integration". En Practical Enterprise Software Development Techniques, 141–53. Berkeley, CA: Apress, 2015. http://dx.doi.org/10.1007/978-1-4842-0620-1_9.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

Lopez, Daniel Andres Pelaez. "Continuous Integration and Deployment". En Full-Stack Web Development with Jakarta EE and Vue.js, 509–60. Berkeley, CA: Apress, 2020. http://dx.doi.org/10.1007/978-1-4842-6342-6_13.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Deshpande, Amit y Dirk Riehle. "Continuous Integration in Open Source Software Development". En IFIP – The International Federation for Information Processing, 273–80. Boston, MA: Springer US, 2008. http://dx.doi.org/10.1007/978-0-387-09684-1_23.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Brockhoff, Klaus. "Customer Integration into Continuous Development of IT-based Services". En The Palgrave Handbook of Managing Continuous Business Transformation, 315–34. London: Palgrave Macmillan UK, 2016. http://dx.doi.org/10.1057/978-1-137-60228-2_14.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

Sheeba, Ganeshayya Shidaganti y Ankur P. Gosar. "A Comparison Study on Various Continuous Integration Tools in Software Development". En Machine Learning for Predictive Analysis, 65–76. Singapore: Springer Singapore, 2020. http://dx.doi.org/10.1007/978-981-15-7106-0_7.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

Leach, David. "Developments and Applications of Continuous Fibre Reinforced Thermoplastics". En Integration of Fundamental Polymer Science and Technology—2, 576–88. Dordrecht: Springer Netherlands, 1988. http://dx.doi.org/10.1007/978-94-009-1361-5_87.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Embury, Suzanne M. y Christopher Page. "Effect of Continuous Integration on Build Health in Undergraduate Team Projects". En Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment, 169–83. Cham: Springer International Publishing, 2019. http://dx.doi.org/10.1007/978-3-030-06019-0_13.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.

Actas de conferencias sobre el tema "Continuous integration and development"

1

Dimitrov, Vladimir Dimitrov y Kolio Nenchev Kolev. "Development of a Programming Continuous Integration System". En 2019 27th National Conference with International Participation (TELECOM). IEEE, 2019. http://dx.doi.org/10.1109/telecom48729.2019.8994900.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

Abdul, Fazreil Amreen y Mensely Cheah Siow Fhang. "Implementing Continuous Integration towards rapid application development". En 2012 International Conference on Innovation Management and Technology Research (ICIMTR). IEEE, 2012. http://dx.doi.org/10.1109/icimtr.2012.6236372.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

Forsteneichner, Christian, Kristin Paetzold y Matthias Metschkoll. "CONTINUOUS INTEGRATION OF MODEL VALIDATION INTO PRODUCT DEVELOPMENT". En 15th International Design Conference. Faculty of Mechanical Engineering and Naval Architecture, University of Zagreb, Croatia; The Design Society, Glasgow, UK, 2018. http://dx.doi.org/10.21278/idc.2018.0231.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Hung, Phan Duy y Do Thai Giang. "Continuous Integration for Android Application Development and Training". En the 2019 3rd International Conference. New York, New York, USA: ACM Press, 2019. http://dx.doi.org/10.1145/3345120.3345158.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

Lai, Sen-Tarng y Fang-Yie Leu. "Applying Continuous Integration for Reducing Web Applications Development Risks". En 2015 10th International Conference on Broadband and Wireless Computing, Communication and Applications (BWCCA). IEEE, 2015. http://dx.doi.org/10.1109/bwcca.2015.54.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Rothermel, Gregg. "Improving regression testing in continuous integration development environments (keynote)". En ESEC/FSE '18: 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. New York, NY, USA: ACM, 2018. http://dx.doi.org/10.1145/3278186.3281454.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Bowyer, Jon y Janet Hughes. "Assessing undergraduate experience of continuous integration and test-driven development". En Proceeding of the 28th international conference. New York, New York, USA: ACM Press, 2006. http://dx.doi.org/10.1145/1134285.1134393.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

Estivill-Castro, Vlad, Rene Hexel y Joshua Stover. "Models Testing Models in Continuous Integration of Model-Driven Development". En Software Engineering and Applications/ 831: Advances in Power and Energy Systems. Calgary,AB,Canada: ACTAPRESS, 2015. http://dx.doi.org/10.2316/p.2015.829-016.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

Elbaum, Sebastian, Gregg Rothermel y John Penix. "Techniques for improving regression testing in continuous integration development environments". En the 22nd ACM SIGSOFT International Symposium. New York, New York, USA: ACM Press, 2014. http://dx.doi.org/10.1145/2635868.2635910.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Hsieh, Chin-Yun, Yu Chin Cheng y Chien-Tsun Chen. "Emerging patterns of continuous integration for cross-platform software development". En the 2nd Asian Conference. New York, New York, USA: ACM Press, 2011. http://dx.doi.org/10.1145/2524629.2524639.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.

Informes sobre el tema "Continuous integration and development"

1

Jha, M. C., R. L. McCormick, R. F. Hogsett, R. M. Rowe y K. R. Anast. Development of an advanced continuous mild gasification process for the production of coproducts. Task 4, System integration studies: Char upgrading. Office of Scientific and Technical Information (OSTI), diciembre de 1991. http://dx.doi.org/10.2172/10145427.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
2

Brinkerhoff, Derick W. y Anna Wetterberg. Governance and Sector Outcomes: Making the Connections. RTI Press, septiembre de 2018. http://dx.doi.org/10.3768/rtipress.2018.pb.0019.1809.

Texto completo
Resumen
A critical issue in international development is how donor-funded programs can support sustainable and long-lasting changes in assisted countries. Among the factors associated with sustainability is improved governance. However, many donor-funded initiatives are focused on achieving results in specific sectors, such as health, education, and agriculture. How can how governance interventions contribute to achieving sector-specific results? This brief explores this question and discusses how international development practice has incorporated recognition of the links between governance and sector outcomes. The brief develops a stylized continuum of how governance elements relate to sector interventions and contribute to expected outcomes. We discuss factors that either impede or impel governance integration and close with some observations regarding prospects for integrated programming. The audience for the brief is the international development policy and practitioner communities, and secondarily, academics with an interest in the topic. Key take-aways include: (1) there is ample evidence of positive contributions from improved governance to sector-specific outcomes, but few guideposts exist for practical and effective governance integration; (2) barriers to integration include urgent sector priorities that overshadow governance concerns, requirements to demonstrate progress towards ambitious sector targets, and complex choices related to measurement; and (3) sustainability and self-reliance are major drivers for integration and are facilitated by the flexibility and adaptation that governance integration enables.
Los estilos APA, Harvard, Vancouver, ISO, etc.
3

Wang, Liming. Continuous Data Integration for Land Use and Transportation Planning and Modeling. Portland State University Library, junio de 2014. http://dx.doi.org/10.15760/trec.37.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
4

Maddux, Gary A. Integrated Product Development Tools Integration and Development. Fort Belvoir, VA: Defense Technical Information Center, julio de 1999. http://dx.doi.org/10.21236/ada377003.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
5

Sedgley, D. W., T. H. Batger y W. R. Call. Development of a continuous duty cryopump. Office of Scientific and Technical Information (OSTI), junio de 1986. http://dx.doi.org/10.2172/5221254.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
6

Pioch, Nicholas J. Continuous Strategy Development for Effects-Based Operations. Fort Belvoir, VA: Defense Technical Information Center, febrero de 2006. http://dx.doi.org/10.21236/ada444918.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
7

Robinson, S. M. Development of a continuous-flow fluidic pump. Office of Scientific and Technical Information (OSTI), agosto de 1985. http://dx.doi.org/10.2172/5354448.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
8

Thomas A. Erickson. EM Task 10 - Technology Development Integration. Office of Scientific and Technical Information (OSTI), noviembre de 1998. http://dx.doi.org/10.2172/3840.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
9

Swinhoe, Martyn Thomas. Model development and data uncertainty integration. Office of Scientific and Technical Information (OSTI), diciembre de 2015. http://dx.doi.org/10.2172/1227409.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
10

Swinhoe, Martyn Thomas. Model development and data uncertainty integration. Office of Scientific and Technical Information (OSTI), diciembre de 2015. http://dx.doi.org/10.2172/1227933.

Texto completo
Los estilos APA, Harvard, Vancouver, ISO, etc.
Ofrecemos descuentos en todos los planes premium para autores cuyas obras están incluidas en selecciones literarias temáticas. ¡Contáctenos para obtener un código promocional único!

Pasar a la bibliografía