...
 
Commits (4)
......@@ -103,4 +103,13 @@ ANNOTATE="Dr. Kersten is the Founder and CEO of Tasktop, he's been a PhD in Comp
address = "New York, NY, USA",
keywords = "developer documentation; framework; grounded theory; open source projects; qualitative studies; software documentation",
ANNOTATE="The authors of this paper are extremely prolific (Dagenais with 16 other papers on ACM and Robillard with 78). This resource informs the discussion on the importance of documentation and how to write good documentation.",
}
%coding sucks
@misc{Lion.2014,
author = {Lion McLionhead},
year = {2014},
title = {Coding Sucks: Why a Job in Programming Is Absolute Hell},
url = {https://www.youtube.com/watch?v=MticYPfFRp8},
urldate = {2019-06-11},
}
\ No newline at end of file
......@@ -11,6 +11,53 @@
\begin{document}
\maketitle
Effective collaboration and teamwork separates good software development teams from bad ones. In the past five years, new and exciting collaboration softwares have been released. This paper will document my experience as a junior developer introducing collaboration software to a team that was relatively unfamiliar with these new softwares. This paper could be an invaluable resource for other teams looking to modernize how they collaborate.
\section{Current Situation}
Relatively unfamiliar is a good term for the experience level of my team and many others like it. The new technologies enable collaboration in new ways. Before these new collaboration tools came out, teams would segregate operation and development of software. My team of developers was no exception we would write applications with little regard for how they would be deployed. I aim to fix this using this new class of software called DevOps software. The name DevOps comes from the softwares' ability to integrate development and operations. With the new DevOps mindset, our team would be simultaneously simpler, better and more marketable.
\subsection{Development Only}
Without DevOps software, developers concern themselves only with development. Issues faced by developers are fundamentally different than issues faced by operations staff. Developers care that their code works on their machine, not in the production environment. The phrase "it works on my machine" is said so often by developers that it has even become a meme used to mock careless developers. Our team was no different. Although operations staff see developers as careless, developers are very careful about the issues they face on a regular basis.
Although operations staff might not agree, getting software working on one machine is hard! In an amazing rant, Lion McLionhead explains the factors that induce stress, and inevitably insanity in programmers. Among the factors: politics, security, confusion, fear of things breaking (which they always do), overwhelming responsibility, deadlines, thinking in strict languages designed for computers not humans, and broken dreams \cite{Lion.2014}. After hearing a list like that, "it works on my machine" incorrectly seems like a reasonable statement. Fortunately, developer's have tools to mitigate some of these problems, and DevOps introduces more!
Writing functional software is very hard when working with developers of diverse backgrounds who must be kept in sync while working on a project. For this reason, perhaps the most challenging problem developers face is differing version of software. Developers use version control software to ensure there aren’t conflicting versions. For example, using a simple version control software like Google docs, a novelist could freely change their rough draft and know they could easily revert these changes without keeping an explicit file named "rough draft." My team, uses GitLab, for version control. GitLab's underlying system level technology, git, is very powerful because it allows multiple developers to keep software version controlled. GitLab provides a very useful interface to git, and recently GitLab has started integrating DevOps capabilities (more on this later).
To make matters worse, developers often neglect their code's documentation. Although documentation neglect incurs huge amounts of technical debt, it speeds up short term development on tight deadlines. Ideally, developers would write a full reference and a getting started tutorial for their code \cite{Dagenais:2010:CED:1882291.1882312}. Without documentation, not only will operations staff struggle to implement the code in production, other developers will struggle to understand a project.
Along with the "it works on my machine" mind-set comes the monolith design pattern. Monolithic projects are designed to run entirely on one machine at a time. This design pattern is simpler for developers because components aren't networked. However, this simplicity incurs technical debt because monoliths have trouble scaling. For example, if an organization has a monolithic website and wants to build a mobile app, they would have to build an entirely new monolithic mobile app without reusing any components from their website.
\subsection{Operations Only}
Although operations staff are generally very responsive, their job is fundamentally not development. This segregation means operational staff may not know how changes to their servers they manage will affect developers.
Simply keeping servers running is a huge challenge. Without DevOps, operations staff generally create virtual machines
If keeping servers up to date and working weren't enough, operations staff have to deal with developers.
green geeks
Documentation
versions
virtual machines
\section{DevOps}
portainer
installing GitLab
%docker & docker-compose & docker-hub
%====================================================
%-----------------references-------------------------
%====================================================
......