What problem needs solving? - GitLab Tutorial

- In order to do CICD well, it helps to first ask a simple question, what problem are we solving? Or to approach it from another perspective what should we be optimizing for? So let's take a look at the big picture process of how software is developed. Whatever tools or methodology a team uses, you can usually map the work to what's called the Software Development Lifecycle or SDLC. The SDLC consists of the following parts: analysis, which is researching a problem or market and identifying a need, design, which is the conceptual design of a solution to the problem. Then development is writing the actual code and creating related content like graphics. Deployment, also known as delivery, is getting the completed product to the end users. It could be anything from updating a web application backend to working with a publisher to get a package product into stores. Maintenance is the ongoing support of the product, often including things like bug fixes. These steps can be represented as a cycle like this. Thinking of it as a cycle helps emphasize that the maintenance stage can naturally lead into the next cycles as issues are identified. The work of CICD generally happens here, but as we'll see, doing CICD well can have an impact on the entire cycle. Looking at the general SDLC cycle, it isn't clear how long each stage is supposed to take or how long the entire cycle takes. That's because it's wildly variable depending on the application and the team. A well-established company looking to break into a new area of business might spend a very long time on this, analysis and design, because a misstep here could tarnish their reputation. A solo app developer might move much more quickly here, testing out a hunch to see if there's a market for it. In the development stage, those might be reversed, with the large company able to allocate people and resources to quickly implement the design solution, but a solo developer would have to work through everything themselves. The other thing that happens in the SDLC is that the lines can overlap and blur. Analysis and design might happen at the same time or working back and forth, or design revisions might happen while development is happening to adjust for unexpected technical issues or enhancements suggested by the development team. In fact, all of these are fairly fluid in terms of timing. This is the real innovation of CICD, because integration and delivery have previously been very rigid events that didn't fit well into the flexible nature of the rest of the process. That's really the answer to the question we started this lesson with, CICD is a way of making those parts of the SDLC more adaptive and allows more back and forth across the entire process.