The Series - An Introduction

# The Series - An Introduction Globally Distributed Software Engineering (GDSE) is the practice of developing software products or components across multiple different countries, often spanning multiple different continents. Whether due to the allure of economic cost benefits, the need for proximity to a localised market or to capitalise on scarce and local resources, it has been a growing trend since before 2001.[^gdse] ![Multiple different teams across the globe working on their own part of a greater whole](https://i.imgur.com/7cEjDna.jpg) > [name=Source: https://globalsoftwareengineering.blogspot.com/2019/05/teaching-in-gdse.html] Distributing the development of a piece of software obviously brings a number of challenges and questions, which are well covered in literature[^gdse][^smite-gdse][^gdse-challenges][^ci-overview]. What should the software do? What is the outsourced software's responsibility in the overall software architecture? Will it need to integrate closely with the rest of the company's software architecture or will it be a separate component? Consequently, how do we set up communication structures in such a way that we can effectively transfer knowlegde between our mainland and offshore teams? What knowledge do we need to transfer? How much knowledge of the system will need to be shared with to the offshore teams? Especially with a monolithic software architecture (i.e. all of your company's software is one big pile of code developed and deployed as one big whole), there's a significant chance that the outsourced developers will have to integrate closely with the system as a whole and will need to learn a lot about its inner workings in order to be productive. This requires a lot of knowledge transfer that does not directly translate into productivity, especially when combined with a high rate of attrition (how fast workers assigned to the project are leaving it to pursue something else) as Šmite et al. have shown[^smite-gdse]. > This series is mainly aimed at managers of development teams, experienced developers, intrigued software engineers and technically inclined company executives. The series not only provides theoretical background regarding microservices, automation and the combination thereof, but also explains some reasoning behind them, as well as practical advice and best practices for their implementation. The articles aim to be more easily digestible than scientific papers on these subjects often are, though we do refer to them for further information. Happy reading! ## [Globally Distributed (micro-)Service Engineering](https://hackmd.io/@gdse-4/deliverable-1) In the first article of this series, we will explain how a microservice architecture can help to mitigate some of these problems or make them significantly easier to solve. Splitting up the system architecture into business-driven domains using Domain Driven Design[^ddd-fowler][^ddd-evans] and building your microservices around that allows for better isolation of the different parts of the system and makes it easier to divide work over multiple teams. We will explain what microservices are, what its advantages and challenges are and how a microservice architecture can be implemented. ## [Automation practices in Globally Distributed Software Engineering (GDSE)](https://hackmd.io/@gdse-4/automation) The second article in this series goes into detail on automation practices in GDSE. We go into depth on what Continuous Integration (CI) and Continuous Delivery / Deployment (CD) is, what its advantages, pitfalls and challenges surrounding its implementation are, as well as explain some best practices and a provide short how-to. However, there are many other ways to apply automation than just CI/CD, so we will also touch upon some other techniques, such as source code generation and developer tooling. ## [Combining Automation & Microservices in Globally Distributed Software Engineering (GDSE)](https://hackmd.io/@gdse-4/microservices-automation) The third and final article in this series explains how both topics of microservices and automation can best be combined in a GDSE setting. `TODO: proper explanation once this article is actually written.` --- > ### About us > We are a group of three MSc Computer Science students from the Delft University of Technology, who are currently parttaking in the IN4185 Globally Distributed Software Engineering course. Together, we have a combined background and interest in software architectures and automation in GDSE, as well as an interest in bringing these complicated subjects to the industry in a somewhat more digestible manner than scientific papers do. > > [name=Bart van Oort BSc][name=Rutger van den Berg BSc][name=Dexter van Leeuwen BSc] [^gdse]: Herbsleb, James & Moitra, Deependra. (2001). Global software development. Software, IEEE. 18. 16 - 20. [https://doi.org/10.1109/52.914732](https://doi.org/10.1109/52.914732). [^smite-gdse]: Šmite, D., Wohlin, C., Gorschek, T. et al. Empirical evidence in global software engineering: a systematic review. Empir Software Eng 15, 91–118 (2010). https://doi.org/10.1007/s10664-009-9123-y [^gdse-challenges]: A. Mockus and J. Herbsleb, "Challenges of global software development," Proceedings Seventh International Software Metrics Symposium, London, UK, 2001, pp. 182-184, doi: https://doi.org/10.1109/METRIC.2001.915526. [^ci-overview]: M. Shahin, M. Ali Babar and L. Zhu, "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices," in IEEE Access, vol. 5, pp. 3909-3943, 2017, doi: 10.1109/ACCESS.2017.2685629. [^ddd-fowler]: https://martinfowler.com/bliki/DomainDrivenDesign.html [^ddd-evans]: Evans, E. (2004). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.