Automatic Builds for The People
Last week I blogged about the difference in culture between Notes development teams and other development teams with regard to using Version Control Systems.
Let’s go one step further, and look at the next natural step in creating an efficient process to deploy Notes databases to different servers automatically.
Currently, this is a hot topic for all development teams regardless of language used. There are numerous case studies, webinars and presentations based on real life stories that prove automating builds not only saves time and money, but ensures consistency and robustness in the databases deployed to testing and production servers.
So what is an ‘Automated Build Process’?
After a database is completed or updated by a developer, there are several additional actions or steps the developer or administrator will need to perform before the database is deployed to a test server so that QA can commence testing, or from a Test server to Production (Figure 1). These steps are your build process, whether you have written them down or not. Note: I have omitted ‘developers copying to the production server’ for reasons I will explain later.
(read more)
Let’s go one step further, and look at the next natural step in creating an efficient process to deploy Notes databases to different servers automatically.
Currently, this is a hot topic for all development teams regardless of language used. There are numerous case studies, webinars and presentations based on real life stories that prove automating builds not only saves time and money, but ensures consistency and robustness in the databases deployed to testing and production servers.
So what is an ‘Automated Build Process’?
After a database is completed or updated by a developer, there are several additional actions or steps the developer or administrator will need to perform before the database is deployed to a test server so that QA can commence testing, or from a Test server to Production (Figure 1). These steps are your build process, whether you have written them down or not. Note: I have omitted ‘developers copying to the production server’ for reasons I will explain later.
(read more)
Once configured, the additional actions described above (i.e. your build process) should automatically execute in the same order every time with the click of a button.
Figure 1 - This topology can apply to logical or physical separation of servers.
Figure 1 shows a simple scenario of a DB going from ‘Test’ to ‘Production’. The following actions need to be taken:
In looking for a build management solution, you should keep in mind that it should be flexible to manage simple applications as well as more complex applications where custom agents need to be executed against a DB. To reduce the configuration work, templates should be available where 90% of the actions and the order they execute are the same for most databases. These templates should then be configurable to allow custom actions to execute on individual databases.
So how long does it take to configure these systems?
Let’s be generous and say that it would take 30-40 minutes to perform core configuration (i.e. Using Teamstudio Build Manager). This includes setting up a common template of attributes including but not limited to; server location for deployment, naming conventions, allowed users and mail addresses for reports. Using the example in Figure 1, again let’s be generous and say that it would take another 20 minutes for each DB you wish to include. The process is complete and all the testers or admins need to do any time they require a deployment is to select a DB and click a button. That’s it! Not much of an investment considering the return.
Frustrated Testers.
This process can also benefit the test team as well as administrators that own the production servers. If developers are copying databases from a development server to a test server, they may overwrite a DB that is part way through a test cycle. The test team will not be happy as they will have to stop and run their tests again. Which is what they will have to do, especially if they are not aware of what has changed or what has been affected.
Changing to a ‘pull’ model rather than a ‘push’ model (above) gives the testers more control over what is tested and when. This process can be repeated for production purposes as well. This is achieved by adding a repository that contains versions of each database (Figure 2). This slightly changes the topology but now developers upload databases to the repository and the test team can then pull out any that are ready for test at their own leisure. Once tested and signed off, these databases can be put back in the repository under a different policy ready for any authorized administrator or manager to deploy to the production server. All at the single click of a button.
Figure 2 - A ‘pull’ process reduces risk and enhances management of databases.
For Managers:
Hopefully these few short benefits have persuaded you to look into automating your build process further. Not only can developers and administrators have more time to perform their primary roles but as this process is now under a workflow type system, all transactions are logged for audit and compliance purposes. When builds are successful, good news, a log is generated. If something does not complete or a threshold of a particular action is not met, for example, some code does not conform to internal coding standards, then an email alert can be set up informing you (or whoever is responsible) that the build did not complete and why it failed.
Good practices also come into play here, Earlier I mentioned developers making changes directly to the production server. As a newbie to Notes I was horrified to learn this occurs. In all formal Computer Science training this is the most heinous crime! Developers should be worried that anything they have changed could affect something they are not aware of, for example shared templates. Testers should be concerned that no quality control is applied – what’s the point of having a QA team if this is happening!?! Managers should be worried that if something does break, how long are users going to be without service?
Let’s face it, no one would fly in an airplane that had a new engine installed that was not tested. No one would go for an organ transplant if the surgeon never trained or decided to perform the procedure using a new technique they had just thought of on the spot. No one would buy a house if the builders had not certified that the ground was not a swamp, bog, or prone to subsidence or earthquakes (OK – admittedly this last has occurred but the residents were not pleased and the houses were destroyed!!!)
Whole books have been written on this topic. These are just a few words on a few of the benefits of implementing an automated build process. To find out more about how to implement this process drop me an email. (Richard_sharpe@teamstudio.com)
Figure 1 - This topology can apply to logical or physical separation of servers.
Figure 1 shows a simple scenario of a DB going from ‘Test’ to ‘Production’. The following actions need to be taken:
- Configure DB properties, names, etc.
- Compile any LotusScript
- Assign the proper ACLs
- Sign the DBEnable any Agents and run them
In looking for a build management solution, you should keep in mind that it should be flexible to manage simple applications as well as more complex applications where custom agents need to be executed against a DB. To reduce the configuration work, templates should be available where 90% of the actions and the order they execute are the same for most databases. These templates should then be configurable to allow custom actions to execute on individual databases.
So how long does it take to configure these systems?
Let’s be generous and say that it would take 30-40 minutes to perform core configuration (i.e. Using Teamstudio Build Manager). This includes setting up a common template of attributes including but not limited to; server location for deployment, naming conventions, allowed users and mail addresses for reports. Using the example in Figure 1, again let’s be generous and say that it would take another 20 minutes for each DB you wish to include. The process is complete and all the testers or admins need to do any time they require a deployment is to select a DB and click a button. That’s it! Not much of an investment considering the return.
Frustrated Testers.
This process can also benefit the test team as well as administrators that own the production servers. If developers are copying databases from a development server to a test server, they may overwrite a DB that is part way through a test cycle. The test team will not be happy as they will have to stop and run their tests again. Which is what they will have to do, especially if they are not aware of what has changed or what has been affected.
Changing to a ‘pull’ model rather than a ‘push’ model (above) gives the testers more control over what is tested and when. This process can be repeated for production purposes as well. This is achieved by adding a repository that contains versions of each database (Figure 2). This slightly changes the topology but now developers upload databases to the repository and the test team can then pull out any that are ready for test at their own leisure. Once tested and signed off, these databases can be put back in the repository under a different policy ready for any authorized administrator or manager to deploy to the production server. All at the single click of a button.
Figure 2 - A ‘pull’ process reduces risk and enhances management of databases.
For Managers:
Hopefully these few short benefits have persuaded you to look into automating your build process further. Not only can developers and administrators have more time to perform their primary roles but as this process is now under a workflow type system, all transactions are logged for audit and compliance purposes. When builds are successful, good news, a log is generated. If something does not complete or a threshold of a particular action is not met, for example, some code does not conform to internal coding standards, then an email alert can be set up informing you (or whoever is responsible) that the build did not complete and why it failed.
Good practices also come into play here, Earlier I mentioned developers making changes directly to the production server. As a newbie to Notes I was horrified to learn this occurs. In all formal Computer Science training this is the most heinous crime! Developers should be worried that anything they have changed could affect something they are not aware of, for example shared templates. Testers should be concerned that no quality control is applied – what’s the point of having a QA team if this is happening!?! Managers should be worried that if something does break, how long are users going to be without service?
Let’s face it, no one would fly in an airplane that had a new engine installed that was not tested. No one would go for an organ transplant if the surgeon never trained or decided to perform the procedure using a new technique they had just thought of on the spot. No one would buy a house if the builders had not certified that the ground was not a swamp, bog, or prone to subsidence or earthquakes (OK – admittedly this last has occurred but the residents were not pleased and the houses were destroyed!!!)
Whole books have been written on this topic. These are just a few words on a few of the benefits of implementing an automated build process. To find out more about how to implement this process drop me an email. (Richard_sharpe@teamstudio.com)
Category Build Process Development Production Best Practices
| Permalink |
|
|
|
|
|
