11/7/2022 0 Comments Shipit deployWhen a commit made the CI red, it was also blocking all other team members from pushing code, because our bug would break their commit as well. And when it did, we had to go through CI logs, which are less user-friendly than local unit test output, in terms of identifying the exact cause of a problem. But it meant slower feedback loops for the dev team, and a clogged pipeline, and an unclean commit tree.Įvery time a bug failed in CI instead of on our local machine, we were waiting an addition 5–8 minutes to find out that something had gone wrong. And sure, it meant that our bugs weren’t making it to the dev environment. Sure, it always made it to green eventually. We’d identify the problem, fix the code, and push the fix. When CI came back red, we would go back, and dive into the logs to figure out what went wrong. So often, our pipeline diagram would look something like this: #Shipit deploy codeOften, the answer to these questions is “no”, and someone winds up pushing broken code to main. You’re heads-down, working on a feature, and you don’t remember… did I actually run all the unit tests one final time before I pushed, after I made that one small tweak that definitely wouldn’t break any tests? Did I remember to run the entire test suite before pushing, as I was running individually target unit tests along the way, only executing the pieces relevant to the code I was changing? Unfortunately, maybe you’re like me, and you’re a forgetful person. And even better than catching bugs in CI is catching them on your local machine, before they ever get merged into the main branch. It’s better to catch bugs in CI than it is in dev. It’s better to catch bugs in dev than it is in prod. In fact, I would argue that the further to the left of the diagram you find out about a failure, the better. And if you’re detecting them all the way over to the right, in prod, that’s not great. However, I don’t even want to get into those, because what I’m talking about today are the places where this pipeline fails. We’ll often have a QA or staging environment, and a production environment further down the pipeline. Of course, there are more steps, further to the right of this diagram. If that’s green and passing, it will do a deploy to a live dev environment, where the feature can be tested and accepted by our PMs. It builds our code and runs our entire test suite in its own environment, clean and isolated from our local development system. From there, a remote continuous integration (CI) system (such as Jenkins, TravisCI, CircleCI, GitLab, etc…) kicks in. When we’re satisfied that a feature is completed, we do a git push to merge it into our main or develop branch. We write tests and write code and run tests in a loop on our local computer. Our development team worked with a pipeline that looked something like this: Deployment Processįirst, a bit of background about why the idea of low-risk deployment practices were important to us. Read on to find out what it is, what motivated its creation, and how those ideas could help you, too. #Shipit deploy softwareMy team wanted to optimize for these values with automated feedback mechanisms in place.Įnter: ship-it - a script developed by my team 1 to help us deploy better software faster, and get quicker feedback when things went wrong. We like to avoid making mistakes when doing so - especially costly or time-consuming ones. We like doing it fast, and doing it well.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |