Team up, it’s easier that way
How many developers does it take to get the work done? Sometimes one is all you need. However, sometimes you have to build a team to achieve a bigger goal. The Internet is full of useful tools and principles for managing a team working on a big project. Continuous Integration is one of them. This article will extol its virtues and briefly describe how to use it in Kentico 9.
Imagine a scenario that's actually fairly common in software development – A few developers are working on a project, and each of them implements a few classes individually. They code them up, they write all sorts of unit tests to ensure that their classes work properly, and they pat themselves on the back thinking that the program is going to be extremely robust because their classes are so well tested. However, they still have one last step, to integrate all the classes. They combine those classes together to create the larger program that the team has just developed, and suddenly the code fails to compile.
If you have ever experienced such a scenario, you will know that it can take quite some time to merge all the changes and resolve all the errors to build the application successfully. And, unfortunately, the compilation is not the hard part, the newly discovered bugs are. It’s highly possible that the separately developed classes won’t work together at all without a good cooperation process.
Continuous Integration
This is the type of situation where Continuous Integration would come in handy. The main goal is to integrate and merge all changes as early and as often as possible. Every change made by a developer is stored in the repository, and another developer can integrate this change straightaway and adapt to it. The best practice is to have an automated server to compile the whole project and run all tests upon every change. The server can then notify the developers in case of any integration troubles. This approach eliminates the possibility of the integration hell most developers know all too well.
Kentico 8
It’s easy to write a custom module in Kentico. It’s also easy to share the code changes using a source control and integrate them as often as you desire. However, web development isn’t just about the code, it’s also about the data in the database.
It’s not a simple task to share code and data changes together between two developers. The code files are versioned in the source control, but the database objects are stored locally. Developers can use the import/export functionality or staging, but it requires some manual steps to do so. Therefore, they usually end up with one shared database and all its disadvantages.
Kentico 9
This has motivated us to implement the Continuous Integration module in Kentico 9. This module allows you to store the database objects in the file system just like the code files. Every data change will automatically update the object’s representation in the Continuous Integration repository.
Therefore, in Kentico 9 a developer can check in a data change with the corresponding code changes into a source control in just one changeset. Another developer is then able to merge or restore these changes. Objects are stored as XML files to ensure good readability and easy collision resolving.
I hope this little sneak peek was interesting for you and you’re eager to hear more about this feature. I will have a webinar on November 30, 2015, and also speak about it at Kentico Connection this year. See you there.