Regarding the idea to create ever smaller commits and see what that changes for you, I want to link to this text by Kent Beck. He is one of the creators of eXtreme Programming.Continue reading Limbo: How low can you go?
You and your team want to improve your quality. I think this is great. But you have a problem: management. Just yesterday I had a great talk with to great developers. They are interested in this topic and they already found ways to increase quality and improve the overall situation. High-fives all around!
Perhaps you are now wondering what the next steps could be. Or you already know the next steps you would like to take. For these to happen you need buy-in from your management. You need time and money to achieve your goals. But you just don’t find a good way to talk with them about your plans and goals.Continue reading Planting seeds
The last few days I wrote about continuous integration without a branching model. I told you who coined the term and who wrote the book about it.
I don’t know about you, but upon hearing of this model, I was reminded of Subversion. If you are doing software development longer than I am, perhaps you even used CVS (Concurrent Versions System). Both systems have the notion of branches. As both systems are centralized version control systems, every commit you check in automatically is available for every other user to use. You don’t commit locally and then push your changes once you’re happy.Continue reading Did you see it?
Bonus, a third advantage: Your team would tend to favour pair programming. For the simple reason that you wouldn’t have pull/merge requests.
I gave you this statement at the end of last week’s email.
Confession: I don’t particularly like pair programming.Continue reading Disadvantages of CI without branches
Yesterday I wrote about what continuous integration means in its purest form. Today I want to share one or two ideas on how that might be good for you.
If you do not work on a (feature) branch, you do not have to merge this branch into the master branch at some point. I don’t know how often you commit. I try to write really small commits (of the size that I change one typo in one comment and commit that already). If you work only on one branch, together with all the other developers, you have to keep your commits small. You have to commit frequently. Otherwise your work might get lost (the same way it could get lost on a branch that receives no commits).Continue reading Advantages of CI without branches
CircleCI, Jenkins, TravisCI (recently acquired), GitLab CI. You know how they work, I believe.
If you want to do Continuous Integration, almost all of us are doing it wrong. (Of course, it doesn’t depend on the tool, but on the people using it…)Continue reading Build Server or Continuous Integration?
A common CI pipeline looks like this:
These are common stages.
Build the code -> Pre-check the code (quality checks like linting etc.) -> Test the code -> Deploy the code
Let’s look deeper into the testing stage:
-> Unit tests -> Integration tests -> Acceptance tests (system tests) -> Performance tests
These tests can be even more sophisticated and have more jobs that run in parallel.Continue reading Do you have a test priority?
This is one of several articles on what I consider the best way to do a pull request. There are many ways to do this. I consider this to be the best way because of my experiences doing it like that with different teams. The results tell me that I am right. But first: What is a pull request?
What is a pull request, or: How should I integrate my changes with the code
To make any of this work, you need to be using a version control hosting provider like GitHub, GitLab or Bitbucket. All of them provide this functionality. Bitbucket even offers it for Mercurial repositories. I use Git with GitHub and GitLab.Continue reading What is a pull request?
A few years ago, I was afraid of updating the Ubuntu system, that our applications ran on. We chose the LTS (long-term support) versions of the OS releases so we wouldn’t have to do this too often. Essentially, we updated when we heard of new critical security updates or when we needed a new feature that was only available in a more recent version (think a Redis update or other services).
The most horrendous possible outcome of this update was the following: The server did not start anymore after rebooting it. Other very annoying outcomes included
- the application did not start
- data could not be loaded
- the application did not work as expected (there was a bug somewhere)
In these cases you had to choose between three options:
- Do nothing (this is always an option 😉)
- Try to locate and fix the problem
- Rollback to an earlier version
If you application has an error you can revert to an earlier version quite easily. You may have build artifacts that you deploy (think
jar in Java-land). For Ruby on Rails apps you can rollback to an earlier release. Capistrano offers to keep ~5 releases (or more if you tell it to do so).
Sidenote: I also had situations where I ran out of releases to rollback to, because the error was there all the time—we just didn’t know about it!
If the problem is not inside your application but in the area surrounding it (the application server, external libraries, network stack etc.) could you rollback there? I know I couldn’t have.
These days I suggest to keep as much information under version control as possible. This includes all the external libraries you are using (
Gemfile.lock) as well as the configuration of your servers, your services and databases and their specific versions. Depending on your deployment setup it still might be hard to recreate a certain environment for your application given these configuration points. But at least you know which version worked. You know the specific versions of all services that worked.
Tools like Puppet, Chef, Ansible and, of course, Docker and Kubernetes make it way easier to (re)create environments today. But that does not free you of the responsibility to know which configuration to actually use. For that you still need proper configuration management.
I am preparing a workshop for a client about this topic. They noticed their needs and want to improve their situation. If this is something that you would be interested as well, then let me know. I could give you some things to read about it or ask the right question so you could figure things out on your own?
A few weeks ago I suggested that you should integrate the usage of Linters into your projects as a first step in monitoring and improving your code’s quality.
If you went that way (or if you are using Linters a longer time already) you most likely adjusted the given rules for your code. Many people start to use ESLint with ReactJS and the Airbnb ruleset. This is totally fine. I bet you didn’t like some of their rules, though. You adjusted them. And perhaps you commited the
.eslintrc.yml to your repository? If you did so, that’s not bad.
I would kindly suggest one small change:
Create a new repository where you keep all your Linter configuration files (
.rubocop.yml etc.). As a next step you clone the new repository to your developers’ computers.
This makes it easier to use the rules in a new project. All projects will be consistent in which rules they use. Your team can cooperate on designing new rules (or changing existing ones) and everybody is only a
git pull away from receiving the new rules.
If you want to get fancy, you can work with symlinks in your projects, so you never need to copy and paste the files. This adds a step to your CI workflow: You have to clone the linter-repo there as well. Otherwise your lint jobs cannot work properly.