SlideShare uma empresa Scribd logo

Er du moden for å levere kontinuerlig?

•Transferir como KEY, PDF•
•
Stein Inge Morisbak
Stein Inge Morisbak

Kontinuerlige Leveranser og Devops praktiseres av svært mange skal man tro buzzen. Ved hjelp av nye verktøy og prosesser dytter virksomheter idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Det er kunden som bestemmer når noe skal ut i produksjon, ikke IT. Og dette får de til uten å kompromisse på kvalitet. Hvem kunne ikke tenke seg å ha det sånn? Hvordan får de det til? Vår erfaring er at det er lite hensiktsmessig, og til en viss grad svært farlig, å forsøke å få til dette i ett jafs. En mer fornuftig tilnærmingsmåte er å bygge stein for stein basert på tilstanden man befinner seg i, og gradvis forbedre situasjonen. Vi har laget en modenhetsmodell for kontinuerlige leveranser som inneholder teknikker og verktøy som bringer en nærmere målet, og det fine med å være på denne "reisen" er at hvert steg gir stor verdi i seg selv. I foredraget vil vi presentere noen erfaringer på godt og vondt med å implementere steg i modellen. Vi vil starte med å presentere modenhetsmodellen, for deretter å ta for oss noen av teknikkene vi har hatt erfaringer med. Disse er; effektiv bruk av versjonskontroll, branch by abstraction, feature toggles, deployment pipelines med Jenkins, infrastruktur som kode med Puppet, virtualisering av produksjonslike miljøer for utvikling og test (Virtualbox, Vagrant), one-click deploy (og tilbakerulling), nedetidfri produksjonssetting og håndtering av databasemigrering (og tilbakerulling).

Tecnologia
1 de 187
ER DU MODEN FOR Å LEVERE KONTINUERLIG? JavaZone 2012 Sveinung Dalatun og Stein Inge Morisbak 13/09/12
IF YOU ARE WONDERING “WHAT COMES AFTER AGILE?,” YOU SHOULD LOOK TOWARDS CONTINUOUS DELIVERY.
Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes. - Jez Humble (http://continuousdelivery.com/)
Fungerende programvare er det primære målet på fremdrift.
KLAR UTVIKLING FERDIG!
KLAR UTVIKLING FERDIG!
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
"All" testing automatisert Automatiserte funksjonelle tester Automatiserte tekniske tester
Teknologirettet
Forretningsrettet Teknologirettet
Forretningsrettet ng ikli utv tte r Stø Teknologirettet
Stø tte r utv ikli ng Teknologirettet Forretningsrettet Kri tise rer p rod u kte t
Stø tte r utv ikli ng Teknologirettet Forretningsrettet Kri tise rer p rod u kte t
Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Teknologirettet
Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Teknologirettet
Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle akseptansetester t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Feature: Teamwork In order to work effectively As a team member I want good communication
Given When Akseptansekriterier Then
Given When Akseptansekriterier Then Given /I have done x/ do Akseptansetester end
Given When Akseptansekriterier Then Given /I have done x/ do Akseptansetester end Kode
Forretningsrettet Funksjonelle akseptansetester t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle akseptansetester Brukbarhetstesting t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Ytelsestester Kri Integrasjonstester Infrastrukturtester Teknologirettet
Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Ytelsestester Kri Integrasjonstester Infrastrukturtester Sikkerhetstester Teknologirettet
Kontinuerlig integrasjon Build/deployment pipeline
<% if (feature.isActive()) { %> <jsp:include page="featureX.jsp" /> <% } %>
“Løs” arkitektur
kode som ktur a stru Infr
FINN 5 FEIL UTVIKLING TEST QA PROD
REFACTORING
REFACTORING
SLAVE MASTER SLAVE SLAVE
http://puppetlabs.com/
Imperativt for Debian: apt-get install vim echo "set nocp" > /etc/vim/vimrc Imperativt for Redhat: yum install vim echo "set nocp" > /etc/vim/vimrc
Imperativt for Debian: Deklarativt uavhengig av OS: apt-get install vim package { "vim": echo "set nocp" > /etc/vim/vimrc ensure => present, } Imperativt for Redhat: file { "/etc/vim/vimrc": content => "set nocp", } yum install vim echo "set nocp" > /etc/vim/vimrc
user { 'elvis': home => '/home/elvis/', uid => '501', gid => '501', shell => '/bin/bash', ensure => 'present', password => 'hemmelig', }
/puppet/modules/apache/manifests/init.pp class apache { package { 'httpd': ensure => 'present', } service { 'httpd': ensure => running, require => Package['httpd'], } }
/puppet/modules/apache/manifests/init.pp class apache { package { 'httpd': ensure => 'present', } service { 'httpd': /puppet/modules/apache/manifests/ssl.pp ensure => running, require => Package['httpd'], } class apache::ssl inherits apache { package { 'mod_ssl': } ensure => 'present', } service['apache'] { require => Package['mod_ssl'], } }
forge https://github.com/puppetlabs/puppet http://forge.puppetlabs.com/
http://vagrantup.com/
UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
Vagrant::Config.run do |config|   config.vm.define :app do |app|     app.vm.box_url = "https://open.bekk.no/debian.box" app.vm.share_folder "/home/elvis/dev", "~/dev" app.vm.provision :puppet do |puppet|      puppet.manifest_file = "app.pp" end   end   config.vm.define :db do |db| db.vm.box_url = "https://open.bekk.no/centos.box" db.vm.provision :puppet do |puppet|      puppet.manifest_file = "app.pp" end   end end
PULL ELLER PUSH?
master pull pull pull slave 1 slave 2 slave 3
master deploy host #! push pull pull pull app app slave 1 slave 2 slave 3 appserver 1 appserver 2 db-server
#!/bin/bash # Usage: deploy.sh <artifact> <version> artifact=$1 version=$2 wget https://nexus.bekk.no/${artifact}/${version}/${artifact}-${version}.zip unzip ${artifact}.zip /etc/init.d/${artifact} stop rm ${artifact} # softlink ln -s ${artifact}-${version} ${artifact} /etc/init.d/${artifact} start
#!/bin/bash # Usage: rollback.sh <artifact> <version> artifact=$1 version=$2 /etc/init.d/${artifact} stop rm ${artifact} # softlink ln -s ${artifact}-${version} ${artifact} /etc/init.d/${artifact} start
#!/bin/bash ######################################## # The script checks if a server is down # Sends an e-mail if they are. # Install it as a cron-job. app=webapp app=/server/bekkopen/$app hostname=`hostname` pid=`ps -ea -o "pid ppid args" | grep -v grep | grep $app | sed -e 's/^ *//' -e 's/ .*//' | head -1` if [ ! $pid ]; then echo "$app on $hostname is down." | mail -s "$app on $hostname is down" stein.inge.morisbak@BEKK.no fi
One-click deploy Automatisert deploy
En ke l te kn olo gi
public class MySessionHandler extends SessionHandler { public MySessionHandler(final Server server, final DataSource dataSource) { super(); setSessionManager(new MyJDBCSessionManager(server, dataSource)); } } public class MyJDBCSessionIdManager extends JDBCSessionIdManager implements SessionIdManager { public MyJDBCSessionIdManager(final Server server, final DataSource ds) { super(server); setDatasource(ds); } }
BIG-IP LASTBALANSERER NODE 1 /online NODE 2 /online NODE 3 /online
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online > ./deploy.sh web-app 1.2
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
@Component public class EmbeddedJettyServer extends Server { public void start(final WebAppContext webappContext) throws Exception { final HandlerCollection handlers = new HandlerCollection(); handlers.addHandler(new ContextHandlerCollection()); handlers.addHandler(webappContext); setHandler(handlers); start(); } }
@Component public class EmbeddedJettyServer extends Server { public void start(final WebAppContext webappContext) throws Exception { final HandlerCollection handlers = new HandlerCollection(); handlers.addHandler(new ContextHandlerCollection()); handlers.addHandler(webappContext); setHandler(handlers); start(); } } public class WebServerMain { public static void main(final String[] args) throws Exception { ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("webAppContext.xml"); EmbeddedJettyServer server = ctx.getBean(EmbeddedJettyServer.class); String url = WebServerMain.class.getResource("/webapp").toExternalForm(); server.start(new WebAppContext(url, "/")); } }
@Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; }
@Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter
@Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener
@Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener ServletHolder servletHolder = new ServletHolder(healthCheckServlet); servletHolder.setName("healthCheck"); ctx.addServlet(new ServletHolder(healtCheckServlet), "/healtCheck.html"); // add servlet
@Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener ServletHolder servletHolder = new ServletHolder(healthCheckServlet); servletHolder.setName("healthCheck"); ctx.addServlet(new ServletHolder(healtCheckServlet), "/healtCheck.html"); // add servlet ServletHolder jspHolder = new ServletHolder(JspServlet.class); jspHolder.setName("login"); jspHolder.setForcedPath("/WEB-INF/jsp/login.jsp"); ctx.addServlet(jspHolder, "/login.html"); // add jsp
EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true
EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties.
EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties.
EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties. Zip-fil som inneholder alt applikasjonen trenger, inkludert oppstartsskript lages med: appassembler-maven-plugin og maven-assembly-plugin.
EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties. Zip-fil som inneholder alt applikasjonen trenger, inkludert oppstartsskript lages med: appassembler-maven-plugin og maven-assembly-plugin. Kjøring av Main-klassen lokalt med exec-maven-plugin, i IDE-et eller java-kommandoen: mvn exec:java java -classpath ... no.bekk.WebServerMain
DATABASEMIGRERING (OG ROLLBACK)
DATABASEMIGRERING (OG ROLLBACK)
EXPAND/CONTRACT-PATTERN
EXPAND/CONTRACT-PATTERN EXPAND: Legg til nye tabeller / kolonner. Tweake indekser. Migrer databasen.
EXPAND/CONTRACT-PATTERN EXPAND: CONTRACT: Legg til nye tabeller / kolonner. Fjern ubrukte kolonner / tabeller / constraints. Tweake indekser. Legg til nye constraints. Migrer databasen.
db v. 3 TID
app v. 14 kompatibel med db v. 3 og 4 db v. 3 deploy app v. 14 TID
app v. 14 kompatibel med db v. 3 og 4 db v. 3 db v. 4 deploy app v. 14 migrer db v. 4 TID
app v. 14 app v. 15 kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 3 db v. 4 deploy deploy app v. 14 app v. 15 migrer db v. 4 TID
app v. 14 app v. 15 app v. 16 kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 3 db v. 4 deploy deploy deploy app v. 14 app v. 15 app v. 16 migrer db v. 4 TID
app v. 14 app v. 15 app v. 16 app v. 17 kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 3 db v. 4 deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 migrer db v. 4 TID
app v. 14 app v. 15 app v. 16 app v. 17 kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 3 db v. 4 db v. 5 deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 migrer db v. 4 migrer db v. 5 TID
app v. 14 app v. 15 app v. 16 app v. 17 app v. 18 kompatibel med kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 5 db v. 3 db v. 4 db v. 5 deploy deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 app v. 17 migrer db v. 4 migrer db v. 5 TID
001_create_initial_tables.sql: CREATE TABLE customer ( firstname VARCHAR(255), lastname VARCHAR(255) ); 002_add_customer_date_of_birth.sql ALTER TABLE customer ADD COLUMN dateofbirth DATETIME; --//@UNDO ALTER TABLE customer DROP COLUMN dateofbirth;
http://www.liquibase.org
<databaseChangeLog> <changeSet id="Legger til kolonne for kontostatus" author="Stein Inge Morisbak"> <addColumn tableName="KONTO"> <column type="VARCHAR(20)" name="STATUS" /> </addColumn> </changeSet> <changeSet id="Migrer kontostatus" author="Stein Inge Morisbak"> <sql> update KONTO set STATUS = 'AKTIV' where AKTIV = 1; update KONTO set STATUS = 'DEAKTIVERT' where AKTIV = 0; </sql> <rollback> update KONTO set AKTIV = 1 where STATUS = 'AKTIV'; update KONTO set AKTIV = 0 where STATUS = 'DEAKTIVERT'; update KONTO set AKTIV = 0 where STATUS = 'STENGT'; </rollback> </changeSet> <changeSet id="Fjerner gammel kolonne for aktiv" author="Stein Inge Morisbak"> <dropColumn tableName="KONTO" columnName="AKTIV"/> <rollback> <addColumn tableName="KONTO"> <column type="NUMBER(1,0)" name="AKTIV"/> </addColumn> </rollback> </changeSet> </databaseChangeLog>
FORMING
XP! Scrum! STORMING FORMING
XP! Scrum! NORMING STORMING FORMING
PERFORMING XP! Scrum! NORMING STORMING FORMING
Failover Smidig Backup Sikkerhet XP Kanban Deployment Drift Lean root-tilgang DBA Retrospekt Virtualisering/Cloud Kunde DEV OPS Marked Pakketering Overvåkning TDD Automatisering Beredskap Versjonskontroll Logging Audit Konfigurasjonsstyring
Failover Smidig Kontinuerlig leveranse Backup Sikkerhet XP Kanban Test Deployment Drift Lean root-tilgang Time to market Raskere feedback DBA Retrospekt Virtualisering/Cloud Kunde DEVOPS Marked Pakketering Overvåkning Kryssfunksjonalitet TDD Automatisering Beredskap Versjonskontroll Samarbeid Logging Audit Infrastruktur som kode Konfigurasjonsstyring
It’s hard enough for software developers to write code that works on their machine. But even when that’s done, there’s a long journey from there to software that’s producing value - since software only produces value when it’s in production. - Martin Fowler (http://martinfowler.com/delivery.html)
TESTING Test kontinuerlig Jo hyppigere leveranser, jo mindre å teste. Test sammen. Utviklere kan teste. Husk å teste ytelse og sikkerhet.
BYGG OG CI 98 Kontinuerlig integrasjon Alle endringer trigger feedbackmekanismene Deployment pipelines
KONFIGURASJONSSTYRING 99 Infrastruktur som kode (deklarativ) Applikasjonen din er ikke infratruktur (imperativ)
DEPLOYRUTINER 100 Felles og repeterbar deployprosess for alle miljø. Automatisert og skriptet. Feature toggles. Nedetidfri deployment. Skal være enkelt å rulle frem og tilbake (også mellom databaseversjoner). Skill databasemigrering og deploy av applikasjonen.
“LØS “ ARKITEKTUR OG ENKEL TEKNOLOGI 101 Enkelt å konfigurere. Enkel å skripte mot. Branch by abstraction.
PROSESS/ORGANISASJON 102 Pull-basert prosess Alltid produksjonssettbar kode. DevOps. Selvorganisering tar tid - kontinuerlig forbedring.
Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
y DevO ps Norwa November: Dan North http://www.meetup.com/DevOps-Norway/

Recomendados

Connector Architecture 1.6 - Tech-days 2010, Hyderabad.
Connector Architecture 1.6 - Tech-days 2010, Hyderabad.Connector Architecture 1.6 - Tech-days 2010, Hyderabad.
Connector Architecture 1.6 - Tech-days 2010, Hyderabad.Jagadish Prasath
 
Demand-Driven Acquisition in the Colorado Alliance of Research Libraries
Demand-Driven Acquisition in the Colorado Alliance of Research LibrariesDemand-Driven Acquisition in the Colorado Alliance of Research Libraries
Demand-Driven Acquisition in the Colorado Alliance of Research LibrariesMichael Levine-Clark
 
косплей
косплейкосплей
косплейHibelli
 
Communication skills
Communication skillsCommunication skills
Communication skillsPriyanka Sawant
 
New fundamentals intro
New fundamentals introNew fundamentals intro
New fundamentals introtimhanni
 
Power point dª graça
Power point dª graçaPower point dª graça
Power point dª graçagracinhadomoinho
 
08 claire vincent long term support.ppt
08 claire vincent long term support.ppt08 claire vincent long term support.ppt
08 claire vincent long term support.pptbluebuilding
 
Kai Gudmestad
Kai GudmestadKai Gudmestad
Kai Gudmestadkaigudmestad
 

Recomendados

Connector Architecture 1.6 - Tech-days 2010, Hyderabad.
Connector Architecture 1.6 - Tech-days 2010, Hyderabad.Connector Architecture 1.6 - Tech-days 2010, Hyderabad.
Connector Architecture 1.6 - Tech-days 2010, Hyderabad.Jagadish Prasath
 
Demand-Driven Acquisition in the Colorado Alliance of Research Libraries
Demand-Driven Acquisition in the Colorado Alliance of Research LibrariesDemand-Driven Acquisition in the Colorado Alliance of Research Libraries
Demand-Driven Acquisition in the Colorado Alliance of Research LibrariesMichael Levine-Clark
 
косплей
косплейкосплей
косплейHibelli
 
Communication skills
Communication skillsCommunication skills
Communication skillsPriyanka Sawant
 
New fundamentals intro
New fundamentals introNew fundamentals intro
New fundamentals introtimhanni
 
Power point dª graça
Power point dª graçaPower point dª graça
Power point dª graçagracinhadomoinho
 
08 claire vincent long term support.ppt
08 claire vincent long term support.ppt08 claire vincent long term support.ppt
08 claire vincent long term support.pptbluebuilding
 
Kai Gudmestad
Kai GudmestadKai Gudmestad
Kai Gudmestadkaigudmestad
 
Media pre production powerpoint
Media pre production powerpoint Media pre production powerpoint
Media pre production powerpoint ecsmedia
 
Cinea's wedding
Cinea's weddingCinea's wedding
Cinea's weddingwangx908
 
Smile education center1
Smile education center1Smile education center1
Smile education center1Amoah Daniel
 
žIrgai ir muzika
žIrgai ir muzikažIrgai ir muzika
žIrgai ir muzikalaauuraa1990
 
Dailyroutines1
Dailyroutines1Dailyroutines1
Dailyroutines1hacercaliskan
 
Gta artwork
Gta artworkGta artwork
Gta artworknathanlvsb
 
Sexualidad ii
Sexualidad iiSexualidad ii
Sexualidad iiFercha Castillo
 
El circo de los cuentos
El circo de los cuentosEl circo de los cuentos
El circo de los cuentospablo picasso
 
Presentation
PresentationPresentation
PresentationKevLoud
 
Presentation
PresentationPresentation
Presentationfrankhigson
 
Pre production 1
Pre production 1Pre production 1
Pre production 1ecsmedia
 
Shot types
Shot typesShot types
Shot typesecsmedia
 
Lesebrett ntnu 2010
Lesebrett ntnu 2010Lesebrett ntnu 2010
Lesebrett ntnu 2010NTNU University
 
TRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System GuideTRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System GuideRachel Phillips
 
Tracks signatory com
Tracks signatory comTracks signatory com
Tracks signatory comRachel Phillips
 
Camera shots
Camera shotsCamera shots
Camera shotsecsmedia
 
Fill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit GenerationFill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit GenerationMohammed Hammouda
 
アクセシビリティへの取り組みの歴史
アクセシビリティへの取り組みの歴史アクセシビリティへの取り組みの歴史
アクセシビリティへの取り組みの歴史Mitsue-Links Co.,Ltd. Accessibility Department
 
Boig per tu
Boig per tuBoig per tu
Boig per tujordialba
 
Oltre l'orientamento
Oltre l'orientamentoOltre l'orientamento
Oltre l'orientamentoFrancesco Delrosso
 
Zero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleZero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleStein Inge Morisbak
 
Orkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store OrganisasjonerOrkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store OrganisasjonerStein Inge Morisbak
 

Mais conteúdo relacionado

Destaque

Media pre production powerpoint
Media pre production powerpoint Media pre production powerpoint
Media pre production powerpoint ecsmedia
 
Cinea's wedding
Cinea's weddingCinea's wedding
Cinea's weddingwangx908
 
Smile education center1
Smile education center1Smile education center1
Smile education center1Amoah Daniel
 
El circo de los cuentos
El circo de los cuentosEl circo de los cuentos
El circo de los cuentospablo picasso
 
Presentation
PresentationPresentation
PresentationKevLoud
 
Pre production 1
Pre production 1Pre production 1
Pre production 1ecsmedia
 
Shot types
Shot typesShot types
Shot typesecsmedia
 
TRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System GuideTRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System GuideRachel Phillips
 
Camera shots
Camera shotsCamera shots
Camera shotsecsmedia
 
Fill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit GenerationFill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit GenerationMohammed Hammouda
 

Destaque (20)

Media pre production powerpoint
Media pre production powerpoint Media pre production powerpoint
Media pre production powerpoint
 
Cinea's wedding
Cinea's weddingCinea's wedding
Cinea's wedding
 
Smile education center1
Smile education center1Smile education center1
Smile education center1
 
žIrgai ir muzika
žIrgai ir muzikažIrgai ir muzika
žIrgai ir muzika
 
Dailyroutines1
Dailyroutines1Dailyroutines1
Dailyroutines1
 
Gta artwork
Gta artworkGta artwork
Gta artwork
 
Sexualidad ii
Sexualidad iiSexualidad ii
Sexualidad ii
 
El circo de los cuentos
El circo de los cuentosEl circo de los cuentos
El circo de los cuentos
 
Presentation
PresentationPresentation
Presentation
 
Presentation
PresentationPresentation
Presentation
 
Pre production 1
Pre production 1Pre production 1
Pre production 1
 
Shot types
Shot typesShot types
Shot types
 
Lesebrett ntnu 2010
Lesebrett ntnu 2010Lesebrett ntnu 2010
Lesebrett ntnu 2010
 
TRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System GuideTRACKS: Faculty/Staff COI System Guide
TRACKS: Faculty/Staff COI System Guide
 
Tracks signatory com
Tracks signatory comTracks signatory com
Tracks signatory com
 
Camera shots
Camera shotsCamera shots
Camera shots
 
Fill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit GenerationFill your Jobs with the Right-Fit Generation
Fill your Jobs with the Right-Fit Generation
 
アクセシビリティへの取り組みの歴史
アクセシビリティへの取り組みの歴史アクセシビリティへの取り組みの歴史
アクセシビリティへの取り組みの歴史
 
Boig per tu
Boig per tuBoig per tu
Boig per tu
 
Oltre l'orientamento
Oltre l'orientamentoOltre l'orientamento
Oltre l'orientamento
 

Mais de Stein Inge Morisbak

Zero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleZero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleStein Inge Morisbak
 
Orkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store OrganisasjonerOrkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store OrganisasjonerStein Inge Morisbak
 
Zero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleZero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleStein Inge Morisbak
 
Verdien av kontinuerlige leveranser
Verdien av kontinuerlige leveranserVerdien av kontinuerlige leveranser
Verdien av kontinuerlige leveranserStein Inge Morisbak
 
Du kan ikke levere kontinuerlig om du har nedetid
Du kan ikke levere kontinuerlig om du har nedetidDu kan ikke levere kontinuerlig om du har nedetid
Du kan ikke levere kontinuerlig om du har nedetidStein Inge Morisbak
 
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!Hvis du ikke leverer kontinuerlig, så er du ikke smidig!
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!Stein Inge Morisbak
 

Mais de Stein Inge Morisbak (11)

Zero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleZero Downtime Deployment with Ansible
Zero Downtime Deployment with Ansible
 
Orkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store OrganisasjonerOrkestrering av IT-utvikling i Store Organisasjoner
Orkestrering av IT-utvikling i Store Organisasjoner
 
Slutt med IT-prosjekter!
Slutt med IT-prosjekter!Slutt med IT-prosjekter!
Slutt med IT-prosjekter!
 
Devops or die!
Devops or die!Devops or die!
Devops or die!
 
Devops eller dø!
Devops eller dø!Devops eller dø!
Devops eller dø!
 
Zero Downtime Deployment with Ansible
Zero Downtime Deployment with AnsibleZero Downtime Deployment with Ansible
Zero Downtime Deployment with Ansible
 
Verdien av kontinuerlige leveranser
Verdien av kontinuerlige leveranserVerdien av kontinuerlige leveranser
Verdien av kontinuerlige leveranser
 
Du kan ikke levere kontinuerlig om du har nedetid
Du kan ikke levere kontinuerlig om du har nedetidDu kan ikke levere kontinuerlig om du har nedetid
Du kan ikke levere kontinuerlig om du har nedetid
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
 
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!Hvis du ikke leverer kontinuerlig, så er du ikke smidig!
Hvis du ikke leverer kontinuerlig, så er du ikke smidig!
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
 

Er du moden for å levere kontinuerlig?

  • 1. ER DU MODEN FOR Å LEVERE KONTINUERLIG? JavaZone 2012 Sveinung Dalatun og Stein Inge Morisbak 13/09/12
  • 2. IF YOU ARE WONDERING “WHAT COMES AFTER AGILE?,” YOU SHOULD LOOK TOWARDS CONTINUOUS DELIVERY.
  • 3. Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
  • 4.
  • 5.
  • 6. Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
  • 7. Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
  • 8. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes. - Jez Humble (http://continuousdelivery.com/)
  • 9. Fungerende programvare er det primære målet på fremdrift.
  • 10.
  • 11. KLAR UTVIKLING FERDIG!
  • 12. KLAR UTVIKLING FERDIG!
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 19. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 20. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 21. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 22. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 23. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 24. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 25. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 26. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 27. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 28. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 29. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 30. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 31. Build/deployment pipeline Selvorganisert team Kontinuerlig integrasjon Pull-basert prosess CI-server Agile 101 Manuelle rutiner Silo-organisasjon “Løs” arkitektur Infrastruktur som kode Enkel teknologi Kontroll på applikasjonskonfigurasjon Best-of-breed Kontroll på avhengigheter “Enterprise” infrastruktur Manuell konfigurasjon “All” testing automatisert One-click deploy Automatiserte funksjonelle tester Automatisert deploy Automatiserte tekniske tester Repeterbar deploy Manuelle tester Manuell deploy
  • 32.
  • 33. "All" testing automatisert Automatiserte funksjonelle tester Automatiserte tekniske tester
  • 34.
  • 35.
  • 38. Forretningsrettet ng ikli utv tte r Stø Teknologirettet
  • 39. Stø tte r utv ikli ng Teknologirettet Forretningsrettet Kri tise rer p rod u kte t
  • 40. Stø tte r utv ikli ng Teknologirettet Forretningsrettet Kri tise rer p rod u kte t
  • 41. Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Teknologirettet
  • 42. Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Teknologirettet
  • 43. Forretningsrettet t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 44. Forretningsrettet Funksjonelle akseptansetester t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 45. Feature: Teamwork In order to work effectively As a team member I want good communication
  • 46.
  • 47. Given When Akseptansekriterier Then
  • 48. Given When Akseptansekriterier Then Given /I have done x/ do Akseptansetester end
  • 49. Given When Akseptansekriterier Then Given /I have done x/ do Akseptansetester end Kode
  • 50. Forretningsrettet Funksjonelle akseptansetester t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 51. Forretningsrettet Funksjonelle akseptansetester Brukbarhetstesting t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 52. Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 53. Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 54. Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 55. Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Ytelsestester Kri Integrasjonstester Infrastrukturtester Teknologirettet
  • 56. Forretningsrettet Funksjonelle Showcasing akseptansetester Brukbarhetstesting t Exploratory testing kte ng u ikli rod utv p rer tte r Unittester tise Stø Ytelsestester Kri Integrasjonstester Infrastrukturtester Sikkerhetstester Teknologirettet
  • 57.
  • 58.
  • 60.
  • 61.
  • 62.
  • 63.
  • 64.
  • 65.
  • 66.
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 73.
  • 74. <% if (feature.isActive()) { %> <jsp:include page="featureX.jsp" /> <% } %>
  • 75.
  • 76.
  • 78.
  • 79.
  • 80.
  • 81.
  • 82.
  • 83.
  • 84. kode som ktur a stru Infr
  • 85. FINN 5 FEIL UTVIKLING TEST QA PROD
  • 86.
  • 87.
  • 88.
  • 89.
  • 92.
  • 93.
  • 94.
  • 95.
  • 96.
  • 97. SLAVE MASTER SLAVE SLAVE
  • 98.
  • 100. Imperativt for Debian: apt-get install vim echo "set nocp" > /etc/vim/vimrc Imperativt for Redhat: yum install vim echo "set nocp" > /etc/vim/vimrc
  • 101. Imperativt for Debian: Deklarativt uavhengig av OS: apt-get install vim package { "vim": echo "set nocp" > /etc/vim/vimrc ensure => present, } Imperativt for Redhat: file { "/etc/vim/vimrc": content => "set nocp", } yum install vim echo "set nocp" > /etc/vim/vimrc
  • 102.
  • 103. user { 'elvis': home => '/home/elvis/', uid => '501', gid => '501', shell => '/bin/bash', ensure => 'present', password => 'hemmelig', }
  • 104. /puppet/modules/apache/manifests/init.pp class apache { package { 'httpd': ensure => 'present', } service { 'httpd': ensure => running, require => Package['httpd'], } }
  • 105. /puppet/modules/apache/manifests/init.pp class apache { package { 'httpd': ensure => 'present', } service { 'httpd': /puppet/modules/apache/manifests/ssl.pp ensure => running, require => Package['httpd'], } class apache::ssl inherits apache { package { 'mod_ssl': } ensure => 'present', } service['apache'] { require => Package['mod_ssl'], } }
  • 106.
  • 107.
  • 108. forge https://github.com/puppetlabs/puppet http://forge.puppetlabs.com/
  • 109.
  • 111. UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
  • 112. UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
  • 113. UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
  • 114. UTVIKLER 1 UTVIKLER 2 UTVIKLER 3 PROD
  • 115. Vagrant::Config.run do |config|   config.vm.define :app do |app|     app.vm.box_url = "https://open.bekk.no/debian.box" app.vm.share_folder "/home/elvis/dev", "~/dev" app.vm.provision :puppet do |puppet|      puppet.manifest_file = "app.pp" end   end   config.vm.define :db do |db| db.vm.box_url = "https://open.bekk.no/centos.box" db.vm.provision :puppet do |puppet|      puppet.manifest_file = "app.pp" end   end end
  • 116.
  • 117.
  • 119. master pull pull pull slave 1 slave 2 slave 3
  • 120. master deploy host #! push pull pull pull app app slave 1 slave 2 slave 3 appserver 1 appserver 2 db-server
  • 121. #!/bin/bash # Usage: deploy.sh <artifact> <version> artifact=$1 version=$2 wget https://nexus.bekk.no/${artifact}/${version}/${artifact}-${version}.zip unzip ${artifact}.zip /etc/init.d/${artifact} stop rm ${artifact} # softlink ln -s ${artifact}-${version} ${artifact} /etc/init.d/${artifact} start
  • 122. #!/bin/bash # Usage: rollback.sh <artifact> <version> artifact=$1 version=$2 /etc/init.d/${artifact} stop rm ${artifact} # softlink ln -s ${artifact}-${version} ${artifact} /etc/init.d/${artifact} start
  • 123. #!/bin/bash ######################################## # The script checks if a server is down # Sends an e-mail if they are. # Install it as a cron-job. app=webapp app=/server/bekkopen/$app hostname=`hostname` pid=`ps -ea -o "pid ppid args" | grep -v grep | grep $app | sed -e 's/^ *//' -e 's/ .*//' | head -1` if [ ! $pid ]; then echo "$app on $hostname is down." | mail -s "$app on $hostname is down" stein.inge.morisbak@BEKK.no fi
  • 124.
  • 125.
  • 126. One-click deploy Automatisert deploy
  • 127. En ke l te kn olo gi
  • 128.
  • 129. public class MySessionHandler extends SessionHandler { public MySessionHandler(final Server server, final DataSource dataSource) { super(); setSessionManager(new MyJDBCSessionManager(server, dataSource)); } } public class MyJDBCSessionIdManager extends JDBCSessionIdManager implements SessionIdManager { public MyJDBCSessionIdManager(final Server server, final DataSource ds) { super(server); setDatasource(ds); } }
  • 130. BIG-IP LASTBALANSERER NODE 1 /online NODE 2 /online NODE 3 /online
  • 131. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
  • 132. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
  • 133. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online > ./deploy.sh web-app 1.2
  • 134. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
  • 135. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
  • 136. BIG-IP LASTBALANSERER NODE 1 /offline /online NODE 2 /online NODE 3 /online
  • 137.
  • 138.
  • 139.
  • 140. @Component public class EmbeddedJettyServer extends Server { public void start(final WebAppContext webappContext) throws Exception { final HandlerCollection handlers = new HandlerCollection(); handlers.addHandler(new ContextHandlerCollection()); handlers.addHandler(webappContext); setHandler(handlers); start(); } }
  • 141. @Component public class EmbeddedJettyServer extends Server { public void start(final WebAppContext webappContext) throws Exception { final HandlerCollection handlers = new HandlerCollection(); handlers.addHandler(new ContextHandlerCollection()); handlers.addHandler(webappContext); setHandler(handlers); start(); } } public class WebServerMain { public static void main(final String[] args) throws Exception { ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("webAppContext.xml"); EmbeddedJettyServer server = ctx.getBean(EmbeddedJettyServer.class); String url = WebServerMain.class.getResource("/webapp").toExternalForm(); server.start(new WebAppContext(url, "/")); } }
  • 142. @Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; }
  • 143. @Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter
  • 144. @Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener
  • 145. @Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener ServletHolder servletHolder = new ServletHolder(healthCheckServlet); servletHolder.setName("healthCheck"); ctx.addServlet(new ServletHolder(healtCheckServlet), "/healtCheck.html"); // add servlet
  • 146. @Autowired public WebServerConfiguration(final ConfigurableApplicationContext ctx, final LoginFilter loginFilter, final MyWebContextListener webContextListener, final HealthCheckServlet healthCheckServlet) { this.ctx = ctx; this.loginFilter = loginFilter; this.webContextListener = webContextListener; this.healthCheckServlet = healthCheckServlet; } ctx.getServletHandler().addFilter("LoginFilter", loginFilter); // add filter ctx.addEventListener(webContextListener); // add listener ServletHolder servletHolder = new ServletHolder(healthCheckServlet); servletHolder.setName("healthCheck"); ctx.addServlet(new ServletHolder(healtCheckServlet), "/healtCheck.html"); // add servlet ServletHolder jspHolder = new ServletHolder(JspServlet.class); jspHolder.setName("login"); jspHolder.setForcedPath("/WEB-INF/jsp/login.jsp"); ctx.addServlet(jspHolder, "/login.html"); // add jsp
  • 147. EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true
  • 148. EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties.
  • 149. EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties.
  • 150. EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties. Zip-fil som inneholder alt applikasjonen trenger, inkludert oppstartsskript lages med: appassembler-maven-plugin og maven-assembly-plugin.
  • 151. EN BUNDLE SOM KAN DEPLOYES HVOR SOM HELST En propertyfil som bundles med applikasjonen: <miljo>.<servernavn>.min.property=true En secret.properties lever i hvert miljø med “hemmelige” properties. Zip-fil som inneholder alt applikasjonen trenger, inkludert oppstartsskript lages med: appassembler-maven-plugin og maven-assembly-plugin. Kjøring av Main-klassen lokalt med exec-maven-plugin, i IDE-et eller java-kommandoen: mvn exec:java java -classpath ... no.bekk.WebServerMain
  • 155. EXPAND/CONTRACT-PATTERN EXPAND: Legg til nye tabeller / kolonner. Tweake indekser. Migrer databasen.
  • 156. EXPAND/CONTRACT-PATTERN EXPAND: CONTRACT: Legg til nye tabeller / kolonner. Fjern ubrukte kolonner / tabeller / constraints. Tweake indekser. Legg til nye constraints. Migrer databasen.
  • 157. db v. 3 TID
  • 158. app v. 14 kompatibel med db v. 3 og 4 db v. 3 deploy app v. 14 TID
  • 159. app v. 14 kompatibel med db v. 3 og 4 db v. 3 db v. 4 deploy app v. 14 migrer db v. 4 TID
  • 160. app v. 14 app v. 15 kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 3 db v. 4 deploy deploy app v. 14 app v. 15 migrer db v. 4 TID
  • 161. app v. 14 app v. 15 app v. 16 kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 3 db v. 4 deploy deploy deploy app v. 14 app v. 15 app v. 16 migrer db v. 4 TID
  • 162. app v. 14 app v. 15 app v. 16 app v. 17 kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 3 db v. 4 deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 migrer db v. 4 TID
  • 163. app v. 14 app v. 15 app v. 16 app v. 17 kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 3 db v. 4 db v. 5 deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 migrer db v. 4 migrer db v. 5 TID
  • 164. app v. 14 app v. 15 app v. 16 app v. 17 app v. 18 kompatibel med kompatibel med kompatibel med kompatibel med kompatibel med db v. 3 og 4 db v. 4 db v. 4 db v. 4 og 5 db v. 5 db v. 3 db v. 4 db v. 5 deploy deploy deploy deploy deploy app v. 14 app v. 15 app v. 16 app v. 16 app v. 17 migrer db v. 4 migrer db v. 5 TID
  • 165. 001_create_initial_tables.sql: CREATE TABLE customer ( firstname VARCHAR(255), lastname VARCHAR(255) ); 002_add_customer_date_of_birth.sql ALTER TABLE customer ADD COLUMN dateofbirth DATETIME; --//@UNDO ALTER TABLE customer DROP COLUMN dateofbirth;
  • 167. <databaseChangeLog> <changeSet id="Legger til kolonne for kontostatus" author="Stein Inge Morisbak"> <addColumn tableName="KONTO"> <column type="VARCHAR(20)" name="STATUS" /> </addColumn> </changeSet> <changeSet id="Migrer kontostatus" author="Stein Inge Morisbak"> <sql> update KONTO set STATUS = 'AKTIV' where AKTIV = 1; update KONTO set STATUS = 'DEAKTIVERT' where AKTIV = 0; </sql> <rollback> update KONTO set AKTIV = 1 where STATUS = 'AKTIV'; update KONTO set AKTIV = 0 where STATUS = 'DEAKTIVERT'; update KONTO set AKTIV = 0 where STATUS = 'STENGT'; </rollback> </changeSet> <changeSet id="Fjerner gammel kolonne for aktiv" author="Stein Inge Morisbak"> <dropColumn tableName="KONTO" columnName="AKTIV"/> <rollback> <addColumn tableName="KONTO"> <column type="NUMBER(1,0)" name="AKTIV"/> </addColumn> </rollback> </changeSet> </databaseChangeLog>
  • 168.
  • 169.
  • 170.
  • 171.
  • 173. XP! Scrum! STORMING FORMING
  • 174. XP! Scrum! NORMING STORMING FORMING
  • 175. PERFORMING XP! Scrum! NORMING STORMING FORMING
  • 176. Failover Smidig Backup Sikkerhet XP Kanban Deployment Drift Lean root-tilgang DBA Retrospekt Virtualisering/Cloud Kunde DEV OPS Marked Pakketering Overvåkning TDD Automatisering Beredskap Versjonskontroll Logging Audit Konfigurasjonsstyring
  • 177. Failover Smidig Kontinuerlig leveranse Backup Sikkerhet XP Kanban Test Deployment Drift Lean root-tilgang Time to market Raskere feedback DBA Retrospekt Virtualisering/Cloud Kunde DEVOPS Marked Pakketering Overvåkning Kryssfunksjonalitet TDD Automatisering Beredskap Versjonskontroll Samarbeid Logging Audit Infrastruktur som kode Konfigurasjonsstyring
  • 178. It’s hard enough for software developers to write code that works on their machine. But even when that’s done, there’s a long journey from there to software that’s producing value - since software only produces value when it’s in production. - Martin Fowler (http://martinfowler.com/delivery.html)
  • 179.
  • 180. TESTING Test kontinuerlig Jo hyppigere leveranser, jo mindre å teste. Test sammen. Utviklere kan teste. Husk å teste ytelse og sikkerhet.
  • 181. BYGG OG CI 98 Kontinuerlig integrasjon Alle endringer trigger feedbackmekanismene Deployment pipelines
  • 182. KONFIGURASJONSSTYRING 99 Infrastruktur som kode (deklarativ) Applikasjonen din er ikke infratruktur (imperativ)
  • 183. DEPLOYRUTINER 100 Felles og repeterbar deployprosess for alle miljø. Automatisert og skriptet. Feature toggles. Nedetidfri deployment. Skal være enkelt å rulle frem og tilbake (også mellom databaseversjoner). Skill databasemigrering og deploy av applikasjonen.
  • 184. “LØS “ ARKITEKTUR OG ENKEL TEKNOLOGI 101 Enkelt å konfigurere. Enkel å skripte mot. Branch by abstraction.
  • 185. PROSESS/ORGANISASJON 102 Pull-basert prosess Alltid produksjonssettbar kode. DevOps. Selvorganisering tar tid - kontinuerlig forbedring.
  • 186. Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
  • 187. y DevO ps Norwa November: Dan North http://www.meetup.com/DevOps-Norway/

Notas do Editor

  1. Jeg er Stein Inge og jeg er Sveinung. Vi skal snakke om en modell for &amp;#xE5; finne ut av hvor man st&amp;#xE5;r i forhold til &amp;#xE5; levere kontinuerlig og hvilke grep man kan gj&amp;#xF8;re for &amp;#xE5; bedre ruste seg til &amp;#xE5; kunne levere kontinuerlig. For kontinuerlige leveranser er i vinden om dagen, og det er noe vi er glad for. (slide: thoughtworks radar )\n
  2. Thoughtworks har for eksempel kontinuerlig leveranse - og en rekke praksiser, verkt&amp;#xF8;y og teknologier som underst&amp;#xF8;tter det - p&amp;#xE5; sin teknologiradar, og den er det mange som ser til. Thoughtworks ser det som en naturlig videreforedling av smidig. If you are wondering &amp;#x201C;What comes after agile?,&amp;#x201D; you should look towards continuous delivery. Veeeeeeel... (slide: 1. prinsipp)\n
  3. Det er i og for seg ikke noe spesielt nytt med det &amp;#xE5; levere kontinuerlig innen smidig. Det har hele tiden v&amp;#xE6;rt meningen at man skal levere kontinuerlig n&amp;#xE5;r man driver med smidig utvikling. Men, det har likevel ikke v&amp;#xE6;rt s&amp;#xE5; vanlig at man gj&amp;#xF8;r det. Og det er rart.\n
  4. &amp;#xC5;rsaken til at det har blitt mer fokus p&amp;#xE5; det n&amp;#xE5;, har kanskje sammenheng med at den metodikken som har blitt r&amp;#xE5;dende innen smidig - alts&amp;#xE5; Scrum - ikke er optimalisert for &amp;#xE5; levere kontinuerlig (klikk) - p&amp;#xE5; grunn av timeboxing, estimering og releaseplaner - f&amp;#xF8;r mini-fossefallet. (slide: par uker til et par m&amp;#xE5;neder)\n
  5. Og det er en setning i smidigmanifestet som ikke burde v&amp;#xE6;rt der i utgangspunktet. (klikk) De burde skippet setningen i midten og holdt seg til &amp;#x201C;Jo oftere, desto bedre&amp;#x201D;. Det burde v&amp;#xE6;re un&amp;#xF8;dvendig &amp;#xE5; spesifisere hvor lenge &amp;#x201C;Jo oftere, desto bedre&amp;#x201D; skal v&amp;#xE6;re.\n
  6. S&amp;#xE5; hva handler egentlig kontinuerlige leveranser om? Jo; det handler i bunn og grunn om &amp;#xE5; redusere ledetid fra id&amp;#xE9; til produksjon. Med det s&amp;#xE5; mener vi at forretning skal sitte i f&amp;#xF8;rersetet og kunne bestemme hva og n&amp;#xE5;r noe skal i produksjon. Og da mener vi ikke at forretning skal legge en plan om at noe skal i produksjon om 1 uke, 2 uker, 1 m&amp;#xE5;ned eller om et halvt &amp;#xE5;r. Nei da mener vi at kunden skal kunne si at han &amp;#xF8;nsker en endring og f&amp;#xE5; se det i produksjon i l&amp;#xF8;pet av dagen eller enda kortere. Det er jo selvsagt urimelig noen ganger - det tar tross alt litt tid &amp;#xE5; utvikle noe - men det betyr at forretning skal kunne se det i produksjon s&amp;#xE5; snart noe er ferdig. Men det er alts&amp;#xE5; ingen andre enn forretning - ikke drift, ikke virksomhetsarkitekten, ikke QA-avdelingen eller utviklingsteamet som skal bestemme n&amp;#xE5;r prodsettingsdatoen skal v&amp;#xE6;re. Og det skal v&amp;#xE6;re s&amp;#xE5; automatisert at prodsetting skal v&amp;#xE6;re like enkelt som &amp;#xE5; trykke p&amp;#xE5; en knapp (slide: fungerende programvare)\n
  7. Framdrift m&amp;#xE5;les alts&amp;#xE5; alene utfra fungerende programvare i produksjon (slide: knapp)\n
  8. Og det er en s&amp;#xE5;nn knapp forretning &amp;#xF8;nsker seg (slide: kanban).\n
  9. For &amp;#xE5; f&amp;#xE5; til det m&amp;#xE5; vi ha en pull-basert prosess. Vi kan ikke drive med masse planlegging i forkant, ikke bruke masse tid p&amp;#xE5; &amp;#xE5; estimere, ikke utvikle oppgaver i parallell - nei, vi m&amp;#xE5; fokusere p&amp;#xE5; den oppgaven som kunden har prioritert &amp;#xE5; jobbe med akkurat n&amp;#xE5;, og trekke den s&amp;#xE5; fort og sikkert som mulig ut i produksjon (klikk). (slide: sisyfos)\n
  10. Det sier seg selv at man ikke bare kan begynne med dette over natta om man ikke har en s&amp;#xE5;nn prosess eller de riktige verkt&amp;#xF8;yene og kvalitetssikringen p&amp;#xE5; plass. V&amp;#xE5;r erfaring er at det er lite hensiktsmessig, og til en viss grad sv&amp;#xE6;rt farlig, &amp;#xE5; fors&amp;#xF8;ke &amp;#xE5; f&amp;#xE5; til dette i ett jafs. En mer fornuftig tiln&amp;#xE6;rmingsm&amp;#xE5;te er &amp;#xE5; bygge stein for stein basert p&amp;#xE5; tilstanden man befinner seg i, og gradvis forbedre situasjonen. Det fine er at hver ting du gj&amp;#xF8;r gir stor verdi i seg selv, s&amp;#xE5; man m&amp;#xE5; ikke gj&amp;#xF8;re alt med en gang. Det er ulikt mange andre smidigrammeverk som sier at; om du ikke gj&amp;#xF8;r alt, s&amp;#xE5; er det ikke rart at du feiler.\n
  11. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  12. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  13. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  14. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  15. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  16. Man m&amp;#xE5; alts&amp;#xE5; finne ut av hva situasjonen er i dag. Om man kryper. S&amp;#xE5; m&amp;#xE5; man l&amp;#xE6;re seg &amp;#xE5; krabbe (slide: krabbe) f&amp;#xF8;r man kan g&amp;#xE5; (slide: g&amp;#xE5;). Og g&amp;#xE5;, f&amp;#xF8;r man kan rock! (djeveltegn)\n
  17. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  18. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  19. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  20. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  21. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  22. I BEKK sin faggruppe for kontinuerlige leveranser og DevOps har vi laget en modenhetsmodell. Den inneholder teknikker og verkt&amp;#xF8;y hvor man kan plassere seg selv, og finne ut av hvor man st&amp;#xE5;r i dag. Innover i modellen finner man tiltak som gj&amp;#xF8;r at du stadig forbedrer deg. Vi kan &amp;#xE6;rlig innr&amp;#xF8;mme at vi ikke har noen prosjekter i dag som alene har implementert alle stegene... Det vi skal presentere er erfaringer med s&amp;#xE5; og si alle stegene i modellen, s&amp;#xE5; det er litt av hvert. De 4 niv&amp;#xE5;ene i modellen er: store utfordringer (krype), baseline (krabbe), medium (g&amp;#xE5;) og avansert (rock!). Dersom du har store utfordringer, s&amp;#xE5; er det viktigste &amp;#xE5; bevege seg derfra og til baseline. Eksempler p&amp;#xE5; store problemer er (klikk) manuelle rutiner for bygging og manglende artefaktrepository, (klikk) manuell konfigurasjon i hvert milj&amp;#xF8; og p&amp;#xE5; hver server, (klikk) manuell deploy og databasemigrering, (klikk) testing mot slutten og at utviklere ikke tester selv, og at du har en testavdeling, (klikk) store enterprise-produkter som skal l&amp;#xF8;se alle problemer (klikk) silo-organisasjon hvor folk ikke sitter sammen, sjeldne prodsettinger og utviklere som ikke har tilgang p&amp;#xE5; produksjonslogger.(slide: med uthevet det vi vil se p&amp;#xE5;):\n
  23. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  24. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  25. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  26. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  27. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  28. Vi vil se p&amp;#xE5; build/deployment pipelines og kontinuerlig integrasjon, (klikk) Infrastruktur som kode og kontroll p&amp;#xE5; applikasjonskonfigurasjon, (klikk) One-click deploy, automatisert deploy og deploy uten nedetid (klikk) Vi vil snakke om testing. (klikk) Vi skal snakke om l&amp;#xF8;s arkitektur og enkel teknologi, (klikk) Og pull-basert prosess har vi allerede snakket om, men vi skal ogs&amp;#xE5; snakke litt om selvorganiserte team og DevOps. Det f&amp;#xF8;rste vi skal snakke om (klikk)\n
  29. er kvalitetssikring. (bytte)\n\nN&amp;#xE5;r man produksjonssetter st&amp;#xF8;tt og stadig, s&amp;#xE5; er det viktig &amp;#xE5; v&amp;#xE6;re sikker p&amp;#xE5; at en gitt releasekandidat holder m&amp;#xE5;l.\n
  30. er kvalitetssikring. (bytte)\n\nN&amp;#xE5;r man produksjonssetter st&amp;#xF8;tt og stadig, s&amp;#xE5; er det viktig &amp;#xE5; v&amp;#xE6;re sikker p&amp;#xE5; at en gitt releasekandidat holder m&amp;#xE5;l.\n
  31. er kvalitetssikring. (bytte)\n\nN&amp;#xE5;r man produksjonssetter st&amp;#xF8;tt og stadig, s&amp;#xE5; er det viktig &amp;#xE5; v&amp;#xE6;re sikker p&amp;#xE5; at en gitt releasekandidat holder m&amp;#xE5;l.\n
  32. Derfor er det viktig at alt av testing blir gjort kontinuerlig, for &amp;#xE5; kunne avdekke feil s&amp;#xE5; hyppig, og tidlig, som mulig.\nDette b&amp;#xF8;r gjelde for alle typer tester som er relevante for prosjektet.\n
  33. Brian Marick deler tester inn i 4 kvadranter:\nDen nedre halvdelen er teknologiretta (verifiserer koden), den &amp;#xF8;vre forretningsretta (verifiserer funksjonelle krav).\nDen venster halvdelen st&amp;#xF8;tter opp under utvikling, den h&amp;#xF8;yre kontrollerer at produktet virkelig leverer det som trengs.\n
  34. Brian Marick deler tester inn i 4 kvadranter:\nDen nedre halvdelen er teknologiretta (verifiserer koden), den &amp;#xF8;vre forretningsretta (verifiserer funksjonelle krav).\nDen venster halvdelen st&amp;#xF8;tter opp under utvikling, den h&amp;#xF8;yre kontrollerer at produktet virkelig leverer det som trengs.\n
  35. Brian Marick deler tester inn i 4 kvadranter:\nDen nedre halvdelen er teknologiretta (verifiserer koden), den &amp;#xF8;vre forretningsretta (verifiserer funksjonelle krav).\nDen venster halvdelen st&amp;#xF8;tter opp under utvikling, den h&amp;#xF8;yre kontrollerer at produktet virkelig leverer det som trengs.\n
  36. Brian Marick deler tester inn i 4 kvadranter:\nDen nedre halvdelen er teknologiretta (verifiserer koden), den &amp;#xF8;vre forretningsretta (verifiserer funksjonelle krav).\nDen venster halvdelen st&amp;#xF8;tter opp under utvikling, den h&amp;#xF8;yre kontrollerer at produktet virkelig leverer det som trengs.\n
  37. De f&amp;#xF8;rste er kjent for de fleste, vi bruker (klikk) unit- og (klikk) integrasjonstester for &amp;#xE5; sikre at appene v&amp;#xE5;re holder m&amp;#xE5;l p&amp;#xE5; et lavt niv&amp;#xE5;, og til &amp;#xE5; drive utviklingen. Da gjennom TDD.\n(klikk) En applikasjon st&amp;#xE5;r sjelden alene, og har en varierende mengde med infrastruktur den avhenger av, som f.eks. apache, database-server o.l. Stein Inge skal snakke om infrastruktur som kode etterp&amp;#xE5;, og testing av denne. Ein b&amp;#xF8;r ogs&amp;#xE5; smoketeste at all infrastrukturen er p&amp;#xE5; plass i test og etter produksjonssetting.\n
  38. De f&amp;#xF8;rste er kjent for de fleste, vi bruker (klikk) unit- og (klikk) integrasjonstester for &amp;#xE5; sikre at appene v&amp;#xE5;re holder m&amp;#xE5;l p&amp;#xE5; et lavt niv&amp;#xE5;, og til &amp;#xE5; drive utviklingen. Da gjennom TDD.\n(klikk) En applikasjon st&amp;#xE5;r sjelden alene, og har en varierende mengde med infrastruktur den avhenger av, som f.eks. apache, database-server o.l. Stein Inge skal snakke om infrastruktur som kode etterp&amp;#xE5;, og testing av denne. Ein b&amp;#xF8;r ogs&amp;#xE5; smoketeste at all infrastrukturen er p&amp;#xE5; plass i test og etter produksjonssetting.\n
  39. De f&amp;#xF8;rste er kjent for de fleste, vi bruker (klikk) unit- og (klikk) integrasjonstester for &amp;#xE5; sikre at appene v&amp;#xE5;re holder m&amp;#xE5;l p&amp;#xE5; et lavt niv&amp;#xE5;, og til &amp;#xE5; drive utviklingen. Da gjennom TDD.\n(klikk) En applikasjon st&amp;#xE5;r sjelden alene, og har en varierende mengde med infrastruktur den avhenger av, som f.eks. apache, database-server o.l. Stein Inge skal snakke om infrastruktur som kode etterp&amp;#xE5;, og testing av denne. Ein b&amp;#xF8;r ogs&amp;#xE5; smoketeste at all infrastrukturen er p&amp;#xE5; plass i test og etter produksjonssetting.\n
  40. N&amp;#xE5;r man leverer til produksjon st&amp;#xF8;tt og stadig, er det viktig &amp;#xE5; vere sikker p&amp;#xE5; at produktet alltid gj&amp;#xF8;r det forretning forventer at det skal gj&amp;#xF8;re. Derfor trenger vi ogs&amp;#xE5; et sett med funksjonelle akseptansetester.\n
  41. Funksjonelle akseptansetester b&amp;#xF8;r ha sitt grunnlag i godt samarbeid. For &amp;#xE5; unng&amp;#xE5; at forretning, testere, drift og utviklere har ulik forst&amp;#xE5;else av hva som skal lages, b&amp;#xF8;r alle interessenter sitte sammen til rett tid. Alle b&amp;#xF8;r v&amp;#xE6;re, og f&amp;#xF8;le seg som, del av ett og samme team, selv om de har ulike spesialiseringer.\n
  42. F.eks. kan f&amp;#xF8;lgende prosess brukes:\nI all hovedsak er det forretning og testere som spesifiserer akseptansekriterier sammen, men det kan ogs&amp;#xE5; v&amp;#xE6;re driftere eller utviklere som b&amp;#xF8;r involveres dersom det er snakk om infrastruktur og/eller tekniske krav.\n\nDeretter b&amp;#xF8;r testeren og utvikleren, eventuelt drifteren, ilag skrive automatiserte tester\n\nog til slutt kan utvikleren og/eller drift implementere funksjonaliteten.\n
  43. F.eks. kan f&amp;#xF8;lgende prosess brukes:\nI all hovedsak er det forretning og testere som spesifiserer akseptansekriterier sammen, men det kan ogs&amp;#xE5; v&amp;#xE6;re driftere eller utviklere som b&amp;#xF8;r involveres dersom det er snakk om infrastruktur og/eller tekniske krav.\n\nDeretter b&amp;#xF8;r testeren og utvikleren, eventuelt drifteren, ilag skrive automatiserte tester\n\nog til slutt kan utvikleren og/eller drift implementere funksjonaliteten.\n
  44. F.eks. kan f&amp;#xF8;lgende prosess brukes:\nI all hovedsak er det forretning og testere som spesifiserer akseptansekriterier sammen, men det kan ogs&amp;#xE5; v&amp;#xE6;re driftere eller utviklere som b&amp;#xF8;r involveres dersom det er snakk om infrastruktur og/eller tekniske krav.\n\nDeretter b&amp;#xF8;r testeren og utvikleren, eventuelt drifteren, ilag skrive automatiserte tester\n\nog til slutt kan utvikleren og/eller drift implementere funksjonaliteten.\n
  45. S&amp;#xE5; har vi brukbarhetstesting (klikk). N&amp;#xE5;r man leverer kontinuerlig og itererativt kan man gj&amp;#xF8;re dette i produksjon. Det er meningen at man skal levere noe som gir forretningsverdi s&amp;#xE5; fort som mulig, og gradvis forbedre funksjonaliteten. Det finnes ikke noe bedre enn &amp;#xE5; teste brukbarhet p&amp;#xE5; reelle brukere. Dette har vi sett at det ofte syndes mot, for eksempel i Scrum, da man anser en brukerhistorie som helt ferdig n&amp;#xE5;r den er i produksjon.\n\nI tillegg har vi showcasing (klikk), som kan v&amp;#xE6;re et godt verkt&amp;#xF8;y for &amp;#xE5; verifisere at forretning virkelig er tilfreds med det som skal ut i produksjon.\nDet kan framleis skje at bugs oppst&amp;#xE5;r ved reell bruk (klikk), derfor b&amp;#xF8;r vi framleis benytte oss av exploratory testing til &amp;#xE5; avdekke feilscenarier vi ikke har tenkt p&amp;#xE5;.\nTestene i denne kvadranten er s&amp;#xE5;ledes til for &amp;#xE5; kontrollere at vi produserer det brukeren virkelig trenger. Til sammenlikning kontrollerer funksjonelle akseptansetester at vi leverer det forretning forventer.\n
  46. S&amp;#xE5; har vi brukbarhetstesting (klikk). N&amp;#xE5;r man leverer kontinuerlig og itererativt kan man gj&amp;#xF8;re dette i produksjon. Det er meningen at man skal levere noe som gir forretningsverdi s&amp;#xE5; fort som mulig, og gradvis forbedre funksjonaliteten. Det finnes ikke noe bedre enn &amp;#xE5; teste brukbarhet p&amp;#xE5; reelle brukere. Dette har vi sett at det ofte syndes mot, for eksempel i Scrum, da man anser en brukerhistorie som helt ferdig n&amp;#xE5;r den er i produksjon.\n\nI tillegg har vi showcasing (klikk), som kan v&amp;#xE6;re et godt verkt&amp;#xF8;y for &amp;#xE5; verifisere at forretning virkelig er tilfreds med det som skal ut i produksjon.\nDet kan framleis skje at bugs oppst&amp;#xE5;r ved reell bruk (klikk), derfor b&amp;#xF8;r vi framleis benytte oss av exploratory testing til &amp;#xE5; avdekke feilscenarier vi ikke har tenkt p&amp;#xE5;.\nTestene i denne kvadranten er s&amp;#xE5;ledes til for &amp;#xE5; kontrollere at vi produserer det brukeren virkelig trenger. Til sammenlikning kontrollerer funksjonelle akseptansetester at vi leverer det forretning forventer.\n
  47. S&amp;#xE5; har vi brukbarhetstesting (klikk). N&amp;#xE5;r man leverer kontinuerlig og itererativt kan man gj&amp;#xF8;re dette i produksjon. Det er meningen at man skal levere noe som gir forretningsverdi s&amp;#xE5; fort som mulig, og gradvis forbedre funksjonaliteten. Det finnes ikke noe bedre enn &amp;#xE5; teste brukbarhet p&amp;#xE5; reelle brukere. Dette har vi sett at det ofte syndes mot, for eksempel i Scrum, da man anser en brukerhistorie som helt ferdig n&amp;#xE5;r den er i produksjon.\n\nI tillegg har vi showcasing (klikk), som kan v&amp;#xE6;re et godt verkt&amp;#xF8;y for &amp;#xE5; verifisere at forretning virkelig er tilfreds med det som skal ut i produksjon.\nDet kan framleis skje at bugs oppst&amp;#xE5;r ved reell bruk (klikk), derfor b&amp;#xF8;r vi framleis benytte oss av exploratory testing til &amp;#xE5; avdekke feilscenarier vi ikke har tenkt p&amp;#xE5;.\nTestene i denne kvadranten er s&amp;#xE5;ledes til for &amp;#xE5; kontrollere at vi produserer det brukeren virkelig trenger. Til sammenlikning kontrollerer funksjonelle akseptansetester at vi leverer det forretning forventer.\n
  48. I siste kvadrant har vi de testene som oftest blir fors&amp;#xF8;mt, iallefall i &amp;#xE5; bli gjort kontinuerlig.\nNemlig (klikk) ytelsestester og (klikk) sikkerhetstester. Iallefall ytelsestester kan med gevinst automatiseres og gj&amp;#xF8;res med faste intervall, for p&amp;#xE5; den m&amp;#xE5;ten lettere se hvordan ytelsen utvikler seg over tid.\n
  49. I siste kvadrant har vi de testene som oftest blir fors&amp;#xF8;mt, iallefall i &amp;#xE5; bli gjort kontinuerlig.\nNemlig (klikk) ytelsestester og (klikk) sikkerhetstester. Iallefall ytelsestester kan med gevinst automatiseres og gj&amp;#xF8;res med faste intervall, for p&amp;#xE5; den m&amp;#xE5;ten lettere se hvordan ytelsen utvikler seg over tid.\n
  50. Hvem b&amp;#xF8;r teste? I utganspunktet alle, men n&amp;#xE5;r man leverer kontinuerlig har vi ikke tid til tunge testprosesser. Det er heller ikke n&amp;#xF8;dvendig fordi vi leverer lite funksjonalitet hver gang vi prodsetter. Ergo er det lite &amp;#xE5; teste. Man b&amp;#xF8;r f&amp;#xE5; akseptanse fra forretning, men dette kan v&amp;#xE6;re noks&amp;#xE5; uformelt ved at en utvikler viser det han har laget p&amp;#xE5; sin maskin. Dersom det er snakk om driftsting b&amp;#xF8;r utviklere teste sammen med driftere. Ellers er det ingenting i veien for at utviklerne tester selv. Helst ved at det er noen andre enn den som har utviklet oppgaven som g&amp;#xE5;r gjennom og tester.\n
  51. Kontinuerlig integrasjon har allerede blitt pratet mye om opp gjennom &amp;#xE5;rene, s&amp;#xE5; det er lite nytt for oss &amp;#xE5; si.\n\nMen det som skal sies: er at skal du levere kontinuerlig, m&amp;#xE5; du ogs&amp;#xE5; integrere minst like kontinuerlig.\n\nDet nytter ikke &amp;#xE5; ha flere features klare til produksjon, n&amp;#xE5;r de ikke er til stede i den samme releasekandidaten.\n\nNoken gode praksiser &amp;#xE5; f&amp;#xE5; med seg er &amp;#xE5; ikke godta feilende bygg, men &amp;#xE5; fikse opp i de med en gang, og at kontinuerlig integrasjon er en praksis, ikke et verkt&amp;#xF8;y.\n
  52. N&amp;#xE5; skal jeg snakke litt om build/deployment pipelines og kontinuerlig integrasjon.\n
  53. N&amp;#xE5; skal jeg snakke litt om build/deployment pipelines og kontinuerlig integrasjon.\n
  54. N&amp;#xE5; skal jeg snakke litt om build/deployment pipelines og kontinuerlig integrasjon.\n
  55. Deployment pipelinen er Kontinuerlig integrasjon tatt ett skritt lenger\n\nog er en m&amp;#xE5;te &amp;#xE5; sikre seg at koden alltid er produksjonssettbar, og at du bygger kvalitet inn i prosessen i stedet for &amp;#xE5; verifisere kvalitet etter at utvikling er &amp;#x201C;ferdig&amp;#x201D;.\n\nPipelinen best&amp;#xE5;r av ei rekke med steg som begynner med at man sjekker inn en endring I versjonskontroll. Det er viktig &amp;#xE5; merke seg at alle endringer b&amp;#xF8;r trigge pipelinen &amp;#x2013; ogs&amp;#xE5; endringer i konfigurasjon.\n\nRekkef&amp;#xF8;lgen p&amp;#xE5; stegene er ikke alltid s&amp;#xE5; viktig, og b&amp;#xF8;r ofte formes etter behov. Det er ikke sikkert at man trenger &amp;#xE5; innf&amp;#xF8;re alle stega engang.\n\nFor at ein deployment pipeline skal gi mening trenger den noe infrastruktur rundt seg:\nsom for eksempel det mest selvsagte, et versjonskontrollsystem, til kildekoden og konfigurasjonsdata,\nog et artefakt repository, til lagring av bin&amp;#xE6;rfiler, testrapporter og ymse metadata det skulle v&amp;#xE6;re behov for.\n
  56. Trigget hver gang en utvikler gj&amp;#xF8;r en check in til VC\n\nKompilerer,\nkj&amp;#xF8;rer unittester,\nog eventuelt kodeanalyse\n\nOg pakketerer til slutt kandidaten slik at den er klar til deploy. Det skal v&amp;#xE6;re den samme kandidaten som g&amp;#xE5;r gjennom hele pipelinen (uten &amp;#xE5; bygge p&amp;#xE5; nytt), slik at vi vet at kandidaten som passerte UAT er den samme som passerte commit steget.\n
  57. Deployer bin&amp;#xE6;rfilene fra forrige steg\n\nKj&amp;#xF8;rer akseptansetestane mot installasjonen\n
  58. P&amp;#xE5; samme m&amp;#xE5;te som akseptansesteget vil dette steget deploye bin&amp;#xE6;rfilene fra commit-steget, konfigurere milj&amp;#xF8;et og kj&amp;#xF8;re testene automatisk.\n\nForskjellen er at det her kan v&amp;#xE6;re hensiktsmessig at det er teamet selv som bestemmer om kandidaten kommer videre I prosessen.\n
  59. N&amp;#xE5;r det kommer til UAT kan testerene selv trigge en deploy til et testmilj&amp;#xF8;, og deretter bestemme om releasekandidaten f&amp;#xE5;r lov til &amp;#xE5; g&amp;#xE5; videre I pipelinen.\n
  60. N&amp;#xE5;r alle forg&amp;#xE5;ende steg er aksepterte kan kandidaten dyttes ut I produksjon med et tastetrykk.\n\nEn deployment pipeline er s&amp;#xE5;ledes en m&amp;#xE5;te &amp;#xE5; forsikre oss om at en releasekandidat virkelig holder m&amp;#xE5;l f&amp;#xF8;r vi eventuelt produksjonssetter den.\n
  61. For &amp;#xE5; lage en Deployment pipeline trengs det knapt mer enn en egen server som kj&amp;#xF8;rer for eksempel Jenkins\n
  62. P&amp;#xE5; SpareBank1 begynte vi med et helt vanlig maven-bygg satt opp I jenkins, som som vanlig ble trigget hver gang vi pushet kode.\n
  63. Om koden kompilerte, og testene passerte, ble det bygget en RPM som ble lagt p&amp;#xE5; en felles tjener (et slags artefaktrepository med andre ord).\n
  64. Et jenkinsbygg kan ogs&amp;#xE5; konfigureres til &amp;#xE5; trigge et annet bygg, dersom bygget g&amp;#xE5;r bra.\n\nI v&amp;#xE5;rt tilfelle satte vi opp et bygg med et bash-skript som tok RPMen, og installerte den p&amp;#xE5; en testtjener.\n\nMerk at det I dette tilfellet lett kan dyttast p&amp;#xE5; med fleire liknande steg, om det skulle vere &amp;#xF8;nskeleg &amp;#xE5; ha ein testtjenar dedikert til testarane, og ein til utviklarane\n
  65. Som et ekstra sikkerhetsnett hadde vi ogs&amp;#xE5; et jenkinsbygg med smoketester som kj&amp;#xF8;rte ved jevne mellomrom.\n\nI stedet for &amp;#xE5; bli trigget av en commit, tok dette bygget ved midnatt &amp;#xE5; installerte den nyeste RPMen p&amp;#xE5; en dedikert testtjener, kj&amp;#xF8;rte opp applikasjonen, og kj&amp;#xF8;rte smoketestene. I v&amp;#xE5;rt tilfelle en suite av WebDriver-tester.\n\nDette er bare en m&amp;#xE5;te &amp;#xE5; lage en enkel deployment pipeline p&amp;#xE5;. Det finst plugins for &amp;#xE5; gj&amp;#xF8;re mye av det samme, iallefall for jenkins, men sikkert ogs&amp;#xE5; for andre systemer.\n
  66. Et av poengene med &amp;#xE5; drive med kontinuerlige leveranser er at man skal f&amp;#xE5; feedback p&amp;#xE5; det man gj&amp;#xF8;r s&amp;#xE5; tidlig som mulig. Mest for &amp;#xE5; sikre at man jobber med s&amp;#xE5; lite overhead som mulig.\n\nFeedbacken gjelder alle testfaser: unittesting, integrasjonstesting, akseptansetesting, og ogs&amp;#xE5; fra brukerene. \n\nEn hindring som ofte kommer I vegen for dette er at man I mange tilfeller vil kontrollere tidspunktet en feature blir gjort synlig for brukerene. Uferdige features som ligger I produksjon kan selvsagt vere en stor risiko for sikkerhet og omd&amp;#xF8;mme.\n
  67. Den tradisjonelle m&amp;#xE5;ten &amp;#xE5; gjere dette p&amp;#xE5; har vore ved &amp;#xE5; nytte feature branching. Ofte ein branch per feature som m&amp;#xE5; kunne leverast separat.\n\nS&amp;#xE5; lenge ein jobber p&amp;#xE5; f&amp;#xE5; features om gangen, teamet er godt samlokalisert, og levetida p&amp;#xE5; kvar branch er kort, s&amp;#xE5; fungerer igrunn feature branching bra nok.\n\nDigipost er eit godt d&amp;#xF8;me p&amp;#xE5; dette.\n\nDet ultimate er n&amp;#xE5;r du berre jobber p&amp;#xE5; ein ting I gongen. D&amp;#xE5; blir I praksis dev-branchen mainline, og ei utrulling berre ei oppdatering av master utan noko som helst form for merge.\n
  68. Men etter kvart som desse to talet p&amp;#xE5; features under utvikling auker, og levetida deira blir lengre, aukar ogs&amp;#xE5; overheaden.\n\nDen mest sj&amp;#xF8;lvsagte overheaden er merging. Om ein gitt branch lever separert lenge nok kan den uunng&amp;#xE5;elige mergen til slutt ta veldig lang tid\n\neg har sj&amp;#xF8;lv vore borti tilfeller p&amp;#xE5; oppmot 3 veker.\n
  69. - I s&amp;#xE5;nne tilfeller kan feature toggles hjelpe oss.\n- Ein feature toggle er til sjuande og sist ein &amp;#x201C;if&amp;#x201D; og ei linje med konfigurasjon som seier &amp;#x201C;av&amp;#x201D; eller &amp;#x201C;p&amp;#xE5;&amp;#x201D;.\n- Med denne teknikken kan me bruke koden sj&amp;#xF8;lv til &amp;#xE5; kontrollere om ein gitt feature er aktiv eller ikkje i eit gitt milj&amp;#xF8;\n- Dette er ofte mest hensiktsmessig under utvikling, der featuren er aktiv i testmilj&amp;#xF8;et, men inaktiv i prod.\n- Etter at featuren er ferdig utvikla, er det sjeldan nokon grunn til &amp;#xE5; spare p&amp;#xE5; den lenger, s&amp;#xE5; det kan vere &amp;#xF8;nskeleg &amp;#xE5; fjerne den, d&amp;#xE5; den d&amp;#xE5; berre er ekstra kompleksitet.\n- \n
  70. Feature toggles kan ogs&amp;#xE5; vere til hjelp om me driv med A/B-testing. D&amp;#xE5; s&amp;#xF8;rger me berre for at eit subset av brukarane g&amp;#xE5;r mot ein feature, medan eit anna subset g&amp;#xE5;r mot ein alternativ feature.\n\nDet kan ogs&amp;#xE5; vere at me har lyst til &amp;#xE5; begrense ein release av ein feature til eit subset av kundane v&amp;#xE5;re, iallefall i starten, til me er sikre p&amp;#xE5; at alt er som det skal vere.\n
  71. Det neste eg skal snakka om (klikk) er laus arkitektur. Me skal sj&amp;#xE5; p&amp;#xE5; korleis ein kan erstatta ein komponent i applikasjonen med ein annan.\n
  72. Det neste eg skal snakka om (klikk) er laus arkitektur. Me skal sj&amp;#xE5; p&amp;#xE5; korleis ein kan erstatta ein komponent i applikasjonen med ein annan.\n
  73. Det neste eg skal snakka om (klikk) er laus arkitektur. Me skal sj&amp;#xE5; p&amp;#xE5; korleis ein kan erstatta ein komponent i applikasjonen med ein annan.\n
  74. Til &amp;#xE5; halde seg p&amp;#xE5; mainline har me ein teknikk i verk&amp;#xF8;ykassa kalla branch-by-abstraction.\n\nUtgangspunket me har n&amp;#xE5;r me byrjer med denne teknikken er ein applikasjon som bruker ein komponent (t.d. Hibernate).\n\nsom me har lyst til &amp;#xE5; bytte ut med ein annan (t.d. JdbcTemplates)\n
  75. Det fyrste me gjer, er &amp;#xE5; introdusere eit abstraksjonslag mellom applikasjonen v&amp;#xE5;r og den gamle komponenten.\n
  76. Dermed kan den nye komponenten ogs&amp;#xE5; implementere det samme interfacet.\n
  77. &amp;#x2026; og vi kan gj&amp;#xF8;re den nye komponenten til vere den gjeldende implementasjonen\n
  78. Og til sist kan vi fjerne abstraksjonslaget om vi ikke lenger har bruk for det.\n
  79. Jeg skal snakke litt om konfigurasjonsstyring og begynner med det mest avanserte (klikk), nemlig infrastruktur som kode. F&amp;#xF8;rst m&amp;#xE5; jeg forklare hva som er m&amp;#xE5;lsetningen med &amp;#xE5; deklarativt kunne spesifisere infrastrukturen som applikasjonene v&amp;#xE5;re skal kj&amp;#xF8;re p&amp;#xE5; og hvorfor det er s&amp;#xE5; viktig (slide: finn 5 feil).\n
  80. Jeg skal snakke litt om konfigurasjonsstyring og begynner med det mest avanserte (klikk), nemlig infrastruktur som kode. F&amp;#xF8;rst m&amp;#xE5; jeg forklare hva som er m&amp;#xE5;lsetningen med &amp;#xE5; deklarativt kunne spesifisere infrastrukturen som applikasjonene v&amp;#xE5;re skal kj&amp;#xF8;re p&amp;#xE5; og hvorfor det er s&amp;#xE5; viktig (slide: finn 5 feil).\n
  81. Jeg skal snakke litt om konfigurasjonsstyring og begynner med det mest avanserte (klikk), nemlig infrastruktur som kode. F&amp;#xF8;rst m&amp;#xE5; jeg forklare hva som er m&amp;#xE5;lsetningen med &amp;#xE5; deklarativt kunne spesifisere infrastrukturen som applikasjonene v&amp;#xE5;re skal kj&amp;#xF8;re p&amp;#xE5; og hvorfor det er s&amp;#xE5; viktig (slide: finn 5 feil).\n
  82. &amp;#xC5;rsaken til at det er viktig er selvsagt at vi &amp;#xF8;nsker produksjonslik infrastruktur i alle milj&amp;#xF8;er - prod - qa - test og ogs&amp;#xE5; lokalt p&amp;#xE5; utvikermaskinene. Det er mange grunner til at vi &amp;#xF8;nsker det. For det f&amp;#xF8;rste er det enkelt &amp;#xE5; kunne sette opp nye milj&amp;#xF8;er. For det andre er det mye lettere &amp;#xE5; feils&amp;#xF8;ke i produksjonslike milj&amp;#xF8;er. For det tredje - og dette er viktig - s&amp;#xE5; kan vi finne feil f&amp;#xF8;r de er i produksjon. (slide: it works on my machine).\n
  83. For alle har vel opplevd at det virker i utvikling, i test, i qa, men s&amp;#xE5; feiler det i produksjon. Og da er det vanskelig &amp;#xE5; feils&amp;#xF8;ke om man ikke har produksjonslike milj&amp;#xF8;er (slide: pile of documents).\n
  84. Andre fordeler med infrastruktur som kode, er at du har dokumentasjon p&amp;#xE5; infrastrukturen etter samme prinsipp som at god kode dokumenterer seg selv. (slide: refactoring) \n
  85. Du kan refaktorere provisjoneringskoden din og evolusjon&amp;#xE6;rt forbedre infrastrukturen din (slide: kloning).\n
  86. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  87. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  88. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  89. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  90. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  91. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  92. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  93. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  94. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  95. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  96. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  97. Dersom du trenger et nytt milj&amp;#xF8; eller skal f&amp;#xE5; en ny utvikler kjapt i gang, kan du kjapt klone et milj&amp;#xF8; ved &amp;#xE5; provisjonere opp en ny maskin. (slide: fordeler)\n
  98. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  99. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  100. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  101. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  102. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  103. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  104. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  105. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  106. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  107. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  108. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  109. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  110. En annen fordel er at du f&amp;#xE5;r versjonskontroll p&amp;#xE5; infrastrukturen din (klikk), og du kan teste provisjoneringsskriptene, deployskriptene, clusteringoppsett, lastbalansering og fallbackmekanismer. (klikk) Du kan automatisere disse testene i CI-serveren din. (klikk). Og du kan automatisere provisjonering av nye bokser. One-click, eller automatisk deploy fra Jenkins. (slide: devops)\n
  111. Da snakker vi DevOps! Utviklere har brakt med seg praksiser de kjenner godt, kildekodekontroll, testdrevet utvikling, kontinuerlig integrasjon og automatisering - inn i driftsf&amp;#xE6;ren. Men; hvordan funker egentlig dette her i praksis da? (slide: puppet)\n
  112. Vi har erfaring med bruk av Puppet for provisjonering (slide: imperativt/deklarativt)\n
  113. Forskjellen mellom tradisjonell m&amp;#xE5;te &amp;#xE5; installere software p&amp;#xE5; og et provisjoneringsverkt&amp;#xF8;y som Puppet er at du tradisjonelt eksplisitt angir hva som skal gj&amp;#xF8;res p&amp;#xE5; en imperativ m&amp;#xE5;te (Gj&amp;#xF8;r f&amp;#xF8;rst dette, s&amp;#xE5; dette) (klikk). Med deklarativ konfigurasjonsstyring beskriver du hvordan infrastrukturen din skal se ut, og det er plattformuavhengig. Hvis noe feiler kan du enkelt modifisere koden og Puppet vil konfigurere opp p&amp;#xE5; nytt. Det kan du ikke gj&amp;#xF8;re hvis det imperative installasjonsskriptet ditt tryner midtveis. Da blir det en masse opprydning og hassle f&amp;#xF8;r du kan kj&amp;#xF8;re det p&amp;#xE5; nytt.\n
  114. Noe av det fine med Puppet er at det er ganske lett &amp;#xE5; komme i gang med. Men, du kan etter ganske kort tid m&amp;#xF8;te &quot;veggen&quot;. Vel og merke hvis du pr&amp;#xF8;ver &amp;#xE5; gj&amp;#xF8;re for mye p&amp;#xE5; en gang eller roter deg inn i noen anti-patterns. For det finnes det en del av. Det kan derfor v&amp;#xE6;re lurt &amp;#xE5; ta et kurs eller &amp;#xE5; f&amp;#xE5; hjelp av noen som har gjort det f&amp;#xF8;r.\nEksempler p&amp;#xE5; anti-patterns er spaghetti-kode, manglende kontinuerlig integrasjon, kun manuelle integrasjonstester og at du glemmer &amp;#xE5; teste med jevne mellomrom. Men, det som er veldig fint med Puppet er at du kan starte i det sm&amp;#xE5; og gradvis bygge ut. Du trenger ikke provisjonere absolutt alt p&amp;#xE5; boksen med en gang.\n
  115. Begynn for eksempel med &amp;#xE5; provisjonere opp en applikasjonsbruker. (slide: provisjonere mysql)\n
  116. Deretter kan du for eksempel fortsette med &amp;#xE5; legge til noen verkt&amp;#xF8;y du &amp;#xF8;nsker skal v&amp;#xE6;re tilgjengelig p&amp;#xE5; maskinen; som her, apache. Du beskriver at apache-server skal v&amp;#xE6;re installert og at den skal installeres som en service. (klikk) S&amp;#xE5; kan du for eksempel konfigurere opp ssl i en egen fil i samme modul. Legg merke til at den arver fra apache-modulen. Du spesifiserer ogs&amp;#xE5; avhengigheter som skal v&amp;#xE6;re p&amp;#xE5; plass ved help av require. N&amp;#xE5;r du f&amp;#xE5;r dreisen p&amp;#xE5; det kan du begynne &amp;#xE5; konfigurere database, installere java, ssh-config og s&amp;#xE5; videre og s&amp;#xE5; videre. (slide: community)\n
  117. S&amp;#xE5; har du full kontroll p&amp;#xE5; infratrukturen din og kan fortsette og forbedre den, akkurat som du forbedrer applikasjonene dine. Og livet som DevOp blir mye enklere.\n
  118. En veldig fin ting er at det finnes en enormt stor community rundt puppet (slide: github og puppetforge)\n
  119. Og en masse ferdigskrevne moduler for s&amp;#xE5; og si alt. Disse kan du rett og slett klone fra puppetforge, github eller andre steder. Delingsviljen i Puppet-milj&amp;#xF8;et er enorm for alle skj&amp;#xF8;nner at om man deler s&amp;#xE5; f&amp;#xE5;r man masse tilbake (slide: puppet job trends)\n
  120. Og Puppet kommer som ei kule i milj&amp;#xF8;et. Dette er satistikk fra jobbannonser p&amp;#xE5; indeed.com.\n
  121. S&amp;#xE5; har vi Vagrant. Vagrant er en Ruby-applikasjon bygd p&amp;#xE5; toppen av Puppet - og VirtualBox. VirtualBox er et virtualiseringsprodukt som lar deg kj&amp;#xF8;re et umodifisert os p&amp;#xE5; toppen av ditt eksisterende OS. Alts&amp;#xE5; en virtuell maskin. (slide: vm p&amp;#xE5; utviklermaskiner)\n
  122. Det vi &amp;#xF8;nsker &amp;#xE5; oppn&amp;#xE5; er &amp;#xE5; replikere produksjonsmilj&amp;#xF8;et p&amp;#xE5; utviklermaskinene. OS-et p&amp;#xE5; utviklermaskinene er sjeldent det samme som i produksjon, s&amp;#xE5; vi m&amp;#xE5; virtualisere produksjons-OS-et lokalt. (klikk) VirtualBox m&amp;#xE5; v&amp;#xE6;re installert. (klikk) Vi m&amp;#xE5; ogs&amp;#xE5; ha skaffet oss, eller laget oss et virtualbox image, med det samme os&apos;et som er i produksjon. Det finnes mange av de p&amp;#xE5; nettet, og det finnes ogs&amp;#xE5; rammeverk, s&amp;#xE5;nn som veewee, som lar deg lage nye os-image p&amp;#xE5; en enkel m&amp;#xE5;te. (klikk) S&amp;#xE5; m&amp;#xE5; vi bruke de samme provisjoneringsskriptene for &amp;#xE5; provisjonere de lokale virtuelle maskinene p&amp;#xE5; utviklermaskinene (slide: vagrant config).\n
  123. Det vi &amp;#xF8;nsker &amp;#xE5; oppn&amp;#xE5; er &amp;#xE5; replikere produksjonsmilj&amp;#xF8;et p&amp;#xE5; utviklermaskinene. OS-et p&amp;#xE5; utviklermaskinene er sjeldent det samme som i produksjon, s&amp;#xE5; vi m&amp;#xE5; virtualisere produksjons-OS-et lokalt. (klikk) VirtualBox m&amp;#xE5; v&amp;#xE6;re installert. (klikk) Vi m&amp;#xE5; ogs&amp;#xE5; ha skaffet oss, eller laget oss et virtualbox image, med det samme os&apos;et som er i produksjon. Det finnes mange av de p&amp;#xE5; nettet, og det finnes ogs&amp;#xE5; rammeverk, s&amp;#xE5;nn som veewee, som lar deg lage nye os-image p&amp;#xE5; en enkel m&amp;#xE5;te. (klikk) S&amp;#xE5; m&amp;#xE5; vi bruke de samme provisjoneringsskriptene for &amp;#xE5; provisjonere de lokale virtuelle maskinene p&amp;#xE5; utviklermaskinene (slide: vagrant config).\n
  124. Det vi &amp;#xF8;nsker &amp;#xE5; oppn&amp;#xE5; er &amp;#xE5; replikere produksjonsmilj&amp;#xF8;et p&amp;#xE5; utviklermaskinene. OS-et p&amp;#xE5; utviklermaskinene er sjeldent det samme som i produksjon, s&amp;#xE5; vi m&amp;#xE5; virtualisere produksjons-OS-et lokalt. (klikk) VirtualBox m&amp;#xE5; v&amp;#xE6;re installert. (klikk) Vi m&amp;#xE5; ogs&amp;#xE5; ha skaffet oss, eller laget oss et virtualbox image, med det samme os&apos;et som er i produksjon. Det finnes mange av de p&amp;#xE5; nettet, og det finnes ogs&amp;#xE5; rammeverk, s&amp;#xE5;nn som veewee, som lar deg lage nye os-image p&amp;#xE5; en enkel m&amp;#xE5;te. (klikk) S&amp;#xE5; m&amp;#xE5; vi bruke de samme provisjoneringsskriptene for &amp;#xE5; provisjonere de lokale virtuelle maskinene p&amp;#xE5; utviklermaskinene (slide: vagrant config).\n
  125. Her er et eksempel p&amp;#xE5; en enkel konfigurasjonsfil. Vi konfigurerer opp et base-box-image. I dette tilfellet Debian for en app-server boks og Cent Os for en databaseboks. Vi konfigurerer opp en folder som skal v&amp;#xE6;re delt. Du kan nemlig dele foldere fra lokal maskin. I dette tilfellet utviklingsfolderen. Dermed har du tilgjengelig kildekoden din p&amp;#xE5; den virtuelle boksen s&amp;#xE5; du kan bedrive utvikling rett i et produksjonslikt milj&amp;#xF8;. Vi angir at vi skal bruke Puppet for &amp;#xE5; provisjonere opp boksene. (slide: jobbe p&amp;#xE5; fly).\n
  126. Med et virtualisert lokalt prod-likt milj&amp;#xF8; kan utviklerne jobbe mot et prodlikt milj&amp;#xF8; p&amp;#xE5; sin egen maskin, du kan ogs&amp;#xE5; jobbe uten nett, for eksempel p&amp;#xE5; et fly - (slide: Norwegian).\n
  127. Med unntak av dette flyet, som har wifi. (slide: kloning)\n
  128. Det er visse ting du ikke b&amp;#xF8;r bruke Puppet til. Du b&amp;#xF8;r ikke deploye applikasjonen din med Puppet. Applikasjonen din er ikke infrastruktur (klikk). Med Puppet s&amp;#xE5; konfigurer du infrastruktur deklarativt i en master slave arkitektur hvor slavene puller konfigurasjonen fra master med ujevne mellomrom. Du &amp;#xF8;nsker mye bedre kontroll og muligheten til &amp;#xE5; f&amp;#xF8;lge med og se p&amp;#xE5; logger ved deploy (klikk). Deploy b&amp;#xF8;r ikke v&amp;#xE6;re deklarativt men imperativt s&amp;#xE5;nn at du kan f&amp;#xF8;lge med p&amp;#xE5; hva som skjer ved deploy. Du pusher alts&amp;#xE5; applikasjonen og databaseendringer til serverne du deployer til (slide: deploy.sh)\n
  129. Det er visse ting du ikke b&amp;#xF8;r bruke Puppet til. Du b&amp;#xF8;r ikke deploye applikasjonen din med Puppet. Applikasjonen din er ikke infrastruktur (klikk). Med Puppet s&amp;#xE5; konfigurer du infrastruktur deklarativt i en master slave arkitektur hvor slavene puller konfigurasjonen fra master med ujevne mellomrom. Du &amp;#xF8;nsker mye bedre kontroll og muligheten til &amp;#xE5; f&amp;#xF8;lge med og se p&amp;#xE5; logger ved deploy (klikk). Deploy b&amp;#xF8;r ikke v&amp;#xE6;re deklarativt men imperativt s&amp;#xE5;nn at du kan f&amp;#xF8;lge med p&amp;#xE5; hva som skjer ved deploy. Du pusher alts&amp;#xE5; applikasjonen og databaseendringer til serverne du deployer til (slide: deploy.sh)\n
  130. Det er visse ting du ikke b&amp;#xF8;r bruke Puppet til. Du b&amp;#xF8;r ikke deploye applikasjonen din med Puppet. Applikasjonen din er ikke infrastruktur (klikk). Med Puppet s&amp;#xE5; konfigurer du infrastruktur deklarativt i en master slave arkitektur hvor slavene puller konfigurasjonen fra master med ujevne mellomrom. Du &amp;#xF8;nsker mye bedre kontroll og muligheten til &amp;#xE5; f&amp;#xF8;lge med og se p&amp;#xE5; logger ved deploy (klikk). Deploy b&amp;#xF8;r ikke v&amp;#xE6;re deklarativt men imperativt s&amp;#xE5;nn at du kan f&amp;#xF8;lge med p&amp;#xE5; hva som skjer ved deploy. Du pusher alts&amp;#xE5; applikasjonen og databaseendringer til serverne du deployer til (slide: deploy.sh)\n
  131. Derfor egner skript seg veldig godt. Her har du verdens enkleste deployskript. Man angir artefakt og versjon som parameer 1 og 2, henter artefakten fra artefaktrepoet, pakker ut den nye versjonen, stopper applikasjonen, flytter soft-link fra gammel til ny applikasjon og starter den nye applikasjonen. (slide: rollback)\n
  132. Rollback er enn&amp;#xE5; enklere. Der stopper vi appen. Flytter symlinken fra ny til forrige versjon og starter opp igjen.\n
  133. &amp;#xC5; kunne skripting er ogs&amp;#xE5; sv&amp;#xE6;rt nyttig i andre sammenhenger, som for eksempel &amp;#xE5; lage enkle overv&amp;#xE5;kningsskript som kan installeres som en cron-jobb. Dette skriptet sender e-post dersom en applikasjon er nede p&amp;#xE5; en av serverne. Det er viktig &amp;#xE5; merke seg at du ikke b&amp;#xF8;r basere overv&amp;#xE5;kningen din p&amp;#xE5; s&amp;#xE5;nne skript. Det finnes mye mer avanserte overv&amp;#xE5;kningsverkt&amp;#xF8;y, som for eksempel Nagios.\n
  134. Bash er et utrolig kraftig verkt&amp;#xF8;y. N&amp;#xE5;r du er nybegynner med bash-skripting s&amp;#xE5; er det fort gjort at skriptene kan bli et mareritt &amp;#xE5; vedlikeholde. Derfor burde du sette deg godt inn i hvordan du kan lage feilh&amp;#xE5;ndtering og rollback. Som jeg sa tidligere, s&amp;#xE5; er bash imperativt, s&amp;#xE5; et skript som feiler midtveis kan ha gjort veldig mye skade, og du kan sannsynligvis ikke bare kj&amp;#xF8;re skriptet p&amp;#xE5; nytt.\n
  135. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  136. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  137. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  138. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  139. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  140. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  141. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  142. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  143. Det neste jeg skal snakke om er nedetidfri produksjonssetting (klikk). Det er flere m&amp;#xE5;ter &amp;#xE5; f&amp;#xE5; til det p&amp;#xE5;, men m&amp;#xE5;ten vi har gjort det p&amp;#xE5; i Digipost, hvor jeg jobber n&amp;#xE5;, er den jeg skal beskrive. At vi f&amp;#xE5;r det til henger sammen med at vi bruker enkel teknologi (klikk). Vi bruker embedded Jetty, som er sv&amp;#xE6;rt fordelaktig &amp;#xE5; jobbe med i forhold til store enterprisy appservere. En vanlig innvending jeg h&amp;#xF8;rer n&amp;#xE5;r jeg snakker om det er at &quot;vi har ikke lov &amp;#xE5; bruke Jetty hos oss, virksomhetarkitekten sier nei, eller ledelsen sier at gull-avtalen vi har med Big Enterprise Company er mye tryggere. Vi har betalt masse for support og det er skummelt &amp;#xE5; bruke Open Source&amp;#x201D;. Alle argumentene er selvsagt bare tull. Hvordan overbevise virksomhetsarkitekter og ledelsen om &amp;#xE5; bruke den beste og enkleste teknologien tilgjengelig er et eget foredrag i seg selv. (slide: driving technical change)\n
  144. Eller dere kan lese denne boken.\n
  145. Uansett; m&amp;#xE5;ten vi har gjort det p&amp;#xE5; er &amp;#xE5; bruke sesjonsreplikering i databasen. Dette er det st&amp;#xF8;tte for out-of-the box i Jetty. Man legger simpelthen til en JDBCSessionHandler som persisterer brukersesjonene til databasen. Dersom en sesjon ikke eksisterer i minne, s&amp;#xE5; sjekkes databasen for om det finnes en sesjon fra en annen server der, og laster inn sesjonen i minne p&amp;#xE5; den nye serveren. Enkelt - men vi m&amp;#xE5; gj&amp;#xF8;re en ting til (klikk).\n
  146. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  147. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  148. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  149. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  150. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  151. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  152. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  153. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  154. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  155. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  156. Foran applikasjonsserverne v&amp;#xE5;re har vi en lastbalanserer som ruter brukerne til den samme serveren som de var p&amp;#xE5; sist. Det kan ta litt tid f&amp;#xF8;r lastbalansereren merker at en node er nede, s&amp;#xE5; den vil vente ganske lenge p&amp;#xE5; at applikasjonsserveren er tilgjengelig f&amp;#xF8;r den ruter brukeren til neste server. Brukeren m&amp;#xE5; da vente lenge p&amp;#xE5; &amp;#xE5; f&amp;#xE5; svar. M&amp;#xE5;ten vi har ordnet det p&amp;#xE5; er som f&amp;#xF8;lger. Det starter med at serveren du &amp;#xF8;nsker &amp;#xE5; ta ned for redeploy melder seg selv ut av lastbalanserer-poolen ved &amp;#xE5; endre returstatus for requesten som lastbalansereren poller p&amp;#xE5; fra online til offline (klikk). S&amp;#xE5; venter vi litte grann og fortsetter &amp;#xE5; serve brukere til lastbalansereren har pinget oss og meldt serveren ut av poolen (klikk) . S&amp;#xE5; kan man deploye til serveren som er tatt ned (klikk). Deretter kan man gj&amp;#xF8;re smoke-tester mot den nye applikasjonen (klikk) f&amp;#xF8;r vi melder den inn igjen i clusteret (klikk)(klikk). S&amp;#xE5; gj&amp;#xF8;r vi tilsvarende med resterende servere (slide: databasemigrering).\n
  157. Jeg skal snakke litt om kontroll p&amp;#xE5; applikasjonskonfig f&amp;#xF8;r vi skal snakke om nedetidfri migrering og rollback av database. Jeg har tenkt &amp;#xE5; bruke et eksempel, nemlig Jetty, for &amp;#xE5; snakke om det.\n
  158. Jeg skal snakke litt om kontroll p&amp;#xE5; applikasjonskonfig f&amp;#xF8;r vi skal snakke om nedetidfri migrering og rollback av database. Jeg har tenkt &amp;#xE5; bruke et eksempel, nemlig Jetty, for &amp;#xE5; snakke om det.\n
  159. Jeg skal snakke litt om kontroll p&amp;#xE5; applikasjonskonfig f&amp;#xF8;r vi skal snakke om nedetidfri migrering og rollback av database. Jeg har tenkt &amp;#xE5; bruke et eksempel, nemlig Jetty, for &amp;#xE5; snakke om det.\n
  160. For &amp;#xF8;yeblikket anser jeg Jetty som den enkleste og beste servlet-containeren i verden, og det &amp;#xE5; jobbe med den er noe helt annet enn hva jeg var vant til for en 5 &amp;#xE5;rs tid siden. Jeg har v&amp;#xE6;rt s&amp;#xE5; heldig &amp;#xE5; bruke Jetty lenge, men det er f&amp;#xF8;rst i det seneste at jeg virkelig har oppdaget at den er god for mye mer enn jeg har brukt tidligere. (klikk)\n
  161. En fin ting med en embedded Jetty-server er at vi kan konfigurere selve serveren som en Spring-b&amp;#xF8;nne og dermed vil Springkonteksten ogs&amp;#xE5; inkludere serveren. Konfigurasjon er tilgjengelig fra hvor som helst i applikasjonskoden. Eller du kan selvf&amp;#xF8;lgelig la v&amp;#xE6;re &amp;#xE5; bruke Spring, men vi bruker alts&amp;#xE5; det (klikk). Main-metoden er superenkel. Den laster spring-konteksten, henter server-b&amp;#xF8;nna fra konteksten, finner stien til webappen, som ikke er en war, men en vanlig utpakket folder, og starter serveren. Det fine med &amp;#xE5; jobbe med en utpakket folder er at det er lett &amp;#xE5; fyre opp serveren med Main-klassen i utvikling uten &amp;#xE5; m&amp;#xE5;tte pakke en war f&amp;#xF8;rst. Og hva skal vi egentlig med en war? Dette er litt forenklet, og en av tingene som mangler er webappkonfigurasjonen, alts&amp;#xE5; det som vanligvis ligger i web.xml. (klikk)\n
  162. For web.xml kan vi erstatte med kode. Her har vi et eksempel. WebServerConfiguration er wiret opp fra Spring og setter applikasjonskonteksten, et filter, en listener og en servlet. For &amp;#xE5; legget til et filter gj&amp;#xF8;r man s&amp;#xE5;nn (klikk). (klikk) en listener, (klikk) en servlet og (klikk) en jsp. Alt kan konfigureres i kode, og det blir mye lettere &amp;#xE5; teste og &amp;#xE5; kj&amp;#xF8;re opp ting lokalt under utvikling. En ting som er rart er at jeg har funnet veldig lite om dette p&amp;#xE5; internett. Det er mange som bruker Jetty, men det er f&amp;#xF8;rst n&amp;#xE5;r du f&amp;#xE5;r p&amp;#xE5; plass disse mekanismene at du virkelig kan lage en ekte embedded webapp container. Det neste vi m&amp;#xE5; gj&amp;#xF8;re er &amp;#xE5; vurdere &amp;#xE5; kutte ut Spring.\n
  163. For web.xml kan vi erstatte med kode. Her har vi et eksempel. WebServerConfiguration er wiret opp fra Spring og setter applikasjonskonteksten, et filter, en listener og en servlet. For &amp;#xE5; legget til et filter gj&amp;#xF8;r man s&amp;#xE5;nn (klikk). (klikk) en listener, (klikk) en servlet og (klikk) en jsp. Alt kan konfigureres i kode, og det blir mye lettere &amp;#xE5; teste og &amp;#xE5; kj&amp;#xF8;re opp ting lokalt under utvikling. En ting som er rart er at jeg har funnet veldig lite om dette p&amp;#xE5; internett. Det er mange som bruker Jetty, men det er f&amp;#xF8;rst n&amp;#xE5;r du f&amp;#xE5;r p&amp;#xE5; plass disse mekanismene at du virkelig kan lage en ekte embedded webapp container. Det neste vi m&amp;#xE5; gj&amp;#xF8;re er &amp;#xE5; vurdere &amp;#xE5; kutte ut Spring.\n
  164. For web.xml kan vi erstatte med kode. Her har vi et eksempel. WebServerConfiguration er wiret opp fra Spring og setter applikasjonskonteksten, et filter, en listener og en servlet. For &amp;#xE5; legget til et filter gj&amp;#xF8;r man s&amp;#xE5;nn (klikk). (klikk) en listener, (klikk) en servlet og (klikk) en jsp. Alt kan konfigureres i kode, og det blir mye lettere &amp;#xE5; teste og &amp;#xE5; kj&amp;#xF8;re opp ting lokalt under utvikling. En ting som er rart er at jeg har funnet veldig lite om dette p&amp;#xE5; internett. Det er mange som bruker Jetty, men det er f&amp;#xF8;rst n&amp;#xE5;r du f&amp;#xE5;r p&amp;#xE5; plass disse mekanismene at du virkelig kan lage en ekte embedded webapp container. Det neste vi m&amp;#xE5; gj&amp;#xF8;re er &amp;#xE5; vurdere &amp;#xE5; kutte ut Spring.\n
  165. For web.xml kan vi erstatte med kode. Her har vi et eksempel. WebServerConfiguration er wiret opp fra Spring og setter applikasjonskonteksten, et filter, en listener og en servlet. For &amp;#xE5; legget til et filter gj&amp;#xF8;r man s&amp;#xE5;nn (klikk). (klikk) en listener, (klikk) en servlet og (klikk) en jsp. Alt kan konfigureres i kode, og det blir mye lettere &amp;#xE5; teste og &amp;#xE5; kj&amp;#xF8;re opp ting lokalt under utvikling. En ting som er rart er at jeg har funnet veldig lite om dette p&amp;#xE5; internett. Det er mange som bruker Jetty, men det er f&amp;#xF8;rst n&amp;#xE5;r du f&amp;#xE5;r p&amp;#xE5; plass disse mekanismene at du virkelig kan lage en ekte embedded webapp container. Det neste vi m&amp;#xE5; gj&amp;#xF8;re er &amp;#xE5; vurdere &amp;#xE5; kutte ut Spring.\n
  166. Jeg liker &amp;#xE5; ha mest mulig konfigurasjon i kode, men det kan v&amp;#xE6;re kjekt &amp;#xE5; ha noen properties som kan endres runtime eller etter restart ogs&amp;#xE5;. Og, for eksempel passord kan uansett ikke v&amp;#xE6;re en del av kildekoden. M&amp;#xE5;ten vi har gjort det p&amp;#xE5; er &amp;#xE5; ha en propertyfil som bundles med applikasjonen. Det er kun en propertyfil og den skal kunne brukes i alle milj&amp;#xF8; og p&amp;#xE5; alle servere, ogs&amp;#xE5; lokalt. Det er selvsagt forskjeller p&amp;#xE5; milj&amp;#xF8;er. Databasen man skal g&amp;#xE5; mot er for eksempel forskjellig lokalt, i test, i qa og i prod. Derfor har vi laget oss en superenkel property-loader hvor du kan prefikse propertiene med milj&amp;#xF8;, for eksempel local, test, qa eller production, eller spesifikt servernavn hvis det er forskjellige propertier p&amp;#xE5; forskjellige servere. Vi har valgt &amp;#xE5; skrive v&amp;#xE5;rt eget, men K&amp;#xE5;re Nilsens Constretto har lignende funksjonalitet (klikk). I tillegg til den ene propertyfilen, s&amp;#xE5; har vi en secret.properties som lever p&amp;#xE5; hver server. Den inneholder hemmelige properties, s&amp;#xE5;nn som passord. Den fila er den eneste konfigurasjonen som lever p&amp;#xE5; serverne. Ganske fett i forhold til hvordan man setter opp sv&amp;#xE6;re enterprise servere.\n
  167. Vi pakker sammen applikasjonen med appassembler-plugin og assembly-plugin. Appassembler plugin gir deg et oppstartsskript og assembly-plugin pakker alt i en zip-fil. Ved deploy pakker du ut zipfilen og kj&amp;#xF8;rer oppstartsskriptet som setter opp classpath og java options og som starter applikasjonen med standard java kommando. Dermed er applikasjonen din kun en java-prosess, som er veldig enkelt &amp;#xE5; forholde seg til driftsmessig (klikk). Lokalt kan du bruke maven-exec-plugin, Run... i IDE-et ditt, eller rett og slett java-kommandoen.\n
  168. Vi pakker sammen applikasjonen med appassembler-plugin og assembly-plugin. Appassembler plugin gir deg et oppstartsskript og assembly-plugin pakker alt i en zip-fil. Ved deploy pakker du ut zipfilen og kj&amp;#xF8;rer oppstartsskriptet som setter opp classpath og java options og som starter applikasjonen med standard java kommando. Dermed er applikasjonen din kun en java-prosess, som er veldig enkelt &amp;#xE5; forholde seg til driftsmessig (klikk). Lokalt kan du bruke maven-exec-plugin, Run... i IDE-et ditt, eller rett og slett java-kommandoen.\n
  169. Vi pakker sammen applikasjonen med appassembler-plugin og assembly-plugin. Appassembler plugin gir deg et oppstartsskript og assembly-plugin pakker alt i en zip-fil. Ved deploy pakker du ut zipfilen og kj&amp;#xF8;rer oppstartsskriptet som setter opp classpath og java options og som starter applikasjonen med standard java kommando. Dermed er applikasjonen din kun en java-prosess, som er veldig enkelt &amp;#xE5; forholde seg til driftsmessig (klikk). Lokalt kan du bruke maven-exec-plugin, Run... i IDE-et ditt, eller rett og slett java-kommandoen.\n
  170. N&amp;#xE5; skal jeg snakke om databasemigrering (klikk) og rollback. For, en vanlig innvending mot hyppig utrulling er: Hvordan h&amp;#xE5;ndteres forskjellige versjoner av databasen. Gj&amp;#xF8;r ikke det nedetidfri prodsetting umulig? Hvordan kan den gamle og den nye applikasjonen kj&amp;#xF8;re mot samme skjema. Det er et slags h&amp;#xF8;na og egget problem: Databaseendringene kan ikke gjennomf&amp;#xF8;res uten &amp;#xE5; bryte med den eksisternde l&amp;#xF8;sningen, og den nye versjonen virker ikke uten endringene du skal gjennomf&amp;#xF8;re. Ikke bra. Vel det finnes l&amp;#xF8;sninger p&amp;#xE5; det. (slide: expand /contract)\n
  171. For eksempel har vi det vi kaller expand/contract pattern. (klikk) Expansion skript er databaseendringer som er trygge &amp;#xE5; legge til uten &amp;#xE5; bryte bakoverkompatibiltet med den eksisterende applikasjonen. Endringer som &amp;#xE5; legge til nye tabeller, legge til kolonner eller &amp;#xE5; tweake indekser faller inn under denne kategorien. (klikk) Contraction-skript er databasemigreringer som rydder opp ting i databasen som ikke trengs lenger etter oppgraderingen. &amp;#xC5; slette kolonner, tabeller eller constraints, og &amp;#xE5; legge til constraints er eksepler p&amp;#xE5; det. Det er ytterst sjelden at vi gj&amp;#xF8;r andre ting som gj&amp;#xF8;r at ikke applikasjonen kan v&amp;#xE6;re kompatibel med to versjoner av databasen. I s&amp;#xE5; tilfelle kan man lage et abstraksjonslag i applikasjonen, s&amp;#xE5;nn som Sveinung viste med abstraction-layer-patternet. Men - som sagt - det slipper du som regel unna. (slide: legg p&amp;#xE5; endringer f&amp;#xF8;r og etter deploy)\n
  172. For eksempel har vi det vi kaller expand/contract pattern. (klikk) Expansion skript er databaseendringer som er trygge &amp;#xE5; legge til uten &amp;#xE5; bryte bakoverkompatibiltet med den eksisterende applikasjonen. Endringer som &amp;#xE5; legge til nye tabeller, legge til kolonner eller &amp;#xE5; tweake indekser faller inn under denne kategorien. (klikk) Contraction-skript er databasemigreringer som rydder opp ting i databasen som ikke trengs lenger etter oppgraderingen. &amp;#xC5; slette kolonner, tabeller eller constraints, og &amp;#xE5; legge til constraints er eksepler p&amp;#xE5; det. Det er ytterst sjelden at vi gj&amp;#xF8;r andre ting som gj&amp;#xF8;r at ikke applikasjonen kan v&amp;#xE6;re kompatibel med to versjoner av databasen. I s&amp;#xE5; tilfelle kan man lage et abstraksjonslag i applikasjonen, s&amp;#xE5;nn som Sveinung viste med abstraction-layer-patternet. Men - som sagt - det slipper du som regel unna. (slide: legg p&amp;#xE5; endringer f&amp;#xF8;r og etter deploy)\n
  173. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  174. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  175. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  176. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  177. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  178. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  179. Ekspansjonsskriptene kj&amp;#xF8;res f&amp;#xF8;r oppgradering av applikasjonen og contraction-skriptene kj&amp;#xF8;rer n&amp;#xE5;r applikasjonen er oppgradert og stabil. Her er et eksempel p&amp;#xE5; hvordan dette funker i praksis. Vi starter med database versjon 3. S&amp;#xE5; deployer vi en applikasjon som er kompatibel med versjon 3 og 4 av databasen som vi enn&amp;#xE5; ikke har migrert. S&amp;#xE5; gj&amp;#xF8;r vi det. S&amp;#xE5; rydder vi opp og deployer en applikasjon som kun er kompatibel med database versjon 4, og s&amp;#xE5; kanskje enda en. Neste gang deployer vi en versjon som er kompatibel med forrige og kommende versjon av databasen, migrerer og rydder opp. Det ligner litt p&amp;#xE5; branch by abstraction faktisk, som Sveinung snakket om tidligere. (slide: sql)\n
  180. Du b&amp;#xF8;r skripte alle databaseendringer inkrementelt og refaktorere databasen. Databaseskjemaet b&amp;#xF8;r behandles p&amp;#xE5; samme m&amp;#xE5;te som kode. Det er kode. S&amp;#xE5; putt de i versjonskontroll og s&amp;#xF8;rg for &amp;#xE5; lage og teste rollback-kode i skriptene. (slide: liquibase)\n
  181. Vi bruker liquibase for &amp;#xE5; lage skriptene v&amp;#xE5;re. (slide: liquibase-skript)\n
  182. Liquibase er xml-basert, og n&amp;#xE5;r du kj&amp;#xF8;rer det sier den for eksempel fra hvis du ikke har skrevet kode for roll-back. Den sier ogs&amp;#xE5; fra om noe er feil med skriptene dine f&amp;#xF8;r du en gang pr&amp;#xF8;ver de mot databasen. Hver release tagges med versjonsnummer i metadata-tabeller i databasen og du kan rulle frem og tilbake mellom versjoner med en enkel kommando. Snedig! (slide: refactor-boka)\n
  183. Og s&amp;#xE5; er det viktig &amp;#xE5; organisere kildekoden for databasen p&amp;#xE5; en ordentlig og strukturert m&amp;#xE5;te, s&amp;#xE5;nn at det er lett &amp;#xE5; finne igjen hvilke endringer som er i hvilken release. &amp;#xC5; refaktorere databasen din er viktig. Du skal ikke v&amp;#xE6;re redd for &amp;#xE5; endre datamodellen. Det har mye &amp;#xE5; si for hvordan resten av koden din vil se ut. Og automatiser databasetester s&amp;#xE5;nn at du kan feile p&amp;#xE5; et tidligst mulig tidspunkt. Da har du tid til &amp;#xE5; fikse problemene. Og, som jeg sa tidligere; produksjonssett databaseendringer adskilt fra applikasjonen. Jo f&amp;#xE6;rre ting du produksjonssetter hver gang - jo f&amp;#xE6;rre ting er det som kan g&amp;#xE5; galt.\n
  184. Til slutt skal jeg snakke litt om selvorganiserte team og litt om DevOps. Er det noe du ikke bare kan begynne med, s&amp;#xE5; er det det. Et velfungerende kryssfunksjonelt selvorganisert team dannes ikke over natta, men over tid.\n
  185. Til slutt skal jeg snakke litt om selvorganiserte team og litt om DevOps. Er det noe du ikke bare kan begynne med, s&amp;#xE5; er det det. Et velfungerende kryssfunksjonelt selvorganisert team dannes ikke over natta, men over tid.\n
  186. Til slutt skal jeg snakke litt om selvorganiserte team og litt om DevOps. Er det noe du ikke bare kan begynne med, s&amp;#xE5; er det det. Et velfungerende kryssfunksjonelt selvorganisert team dannes ikke over natta, men over tid.\n
  187. Selvorganisering handler om &amp;#xE5; sette sammen et team og gi de en eller flere oppgaver de skal l&amp;#xF8;se. Teamet finner selv ut av hvordan oppgavene skal l&amp;#xF8;ses og hvordan de skal m&amp;#xE5;le fremdrift, dele opp oppgavene og ikke minst; hvordan de skal bli bedre. Noen rammer: Teamsammensetning er viktig: &amp;#x201C;Helt team&amp;#x201D;: Alle som trengs for &amp;#xE5; konvertere behov til fungerende software er en del av teamet (inkludert forretning, drift, designere, interaksjonsdesignere, testere og utviklere) Det er flat organisering: Dersom en eller to personer bestemmer hva og hvordan andre skal gj&amp;#xF8;re jobben havner man fort i &amp;#x201C;command and control&amp;#x201D;-situasjon. (klikk).\n
  188. Tuckman har noe han kaller stages of group development, og jeg kjenner meg veldig igjen i disse stegene, s&amp;#xE5; derfor vil jeg dele det med dere. Det f&amp;#xF8;rste er &amp;#x201C;forming&amp;#x201D;: Det er som f&amp;#xF8;rste skoledag, usikre p&amp;#xE5; hverandre, lite uenighet, ingen stikker seg frem, alle lurer p&amp;#xE5; hvem som vil dominere. Neste steg er &amp;#x201C;Storming&amp;#x201D;: Da er det uenighet, konkurerende synspunkter, konfrontasjon og fare for &amp;#xE5; ikke bli enige. S&amp;#xE5;nn var det for eksempel i Digipost hvor vi hadde veldig topptung bemanning og alle hadde sterke meninger om alt. N&amp;#xE5;r vi fikk inn noen juniorer ble det endelig noen som utviklet noe. I Norming er det enighet om rammer for arbeidet, man har bestemt seg for et sett med regler, og det er relativt effektivt, typisk Scrum. S&amp;#xE5; &amp;#x201C;Performing&amp;#x201D;: Da kjenner alle hverandres svakheter og styrker og har evne til &amp;#xE5; tilpasse seg enhver oppgave og &amp;#xE5; l&amp;#xF8;se denne som et lag. Ikke v&amp;#xE6;re redd for &amp;#xE5; tilpasse teamet underveis for &amp;#xE5; f&amp;#xE5; perfekt sammensetning. For eksempel ved &amp;#xE5; ha en god blanding av erfarne og juniorer. Det er fort gjort at fasene stagnerer etter &amp;#x201C;Norming&amp;#x201D;, eller enda v&amp;#xE6;rre; p&amp;#xE5; Storming. Da m&amp;#xE5; det tas grep.\n
  189. Tuckman har noe han kaller stages of group development, og jeg kjenner meg veldig igjen i disse stegene, s&amp;#xE5; derfor vil jeg dele det med dere. Det f&amp;#xF8;rste er &amp;#x201C;forming&amp;#x201D;: Det er som f&amp;#xF8;rste skoledag, usikre p&amp;#xE5; hverandre, lite uenighet, ingen stikker seg frem, alle lurer p&amp;#xE5; hvem som vil dominere. Neste steg er &amp;#x201C;Storming&amp;#x201D;: Da er det uenighet, konkurerende synspunkter, konfrontasjon og fare for &amp;#xE5; ikke bli enige. S&amp;#xE5;nn var det for eksempel i Digipost hvor vi hadde veldig topptung bemanning og alle hadde sterke meninger om alt. N&amp;#xE5;r vi fikk inn noen juniorer ble det endelig noen som utviklet noe. I Norming er det enighet om rammer for arbeidet, man har bestemt seg for et sett med regler, og det er relativt effektivt, typisk Scrum. S&amp;#xE5; &amp;#x201C;Performing&amp;#x201D;: Da kjenner alle hverandres svakheter og styrker og har evne til &amp;#xE5; tilpasse seg enhver oppgave og &amp;#xE5; l&amp;#xF8;se denne som et lag. Ikke v&amp;#xE6;re redd for &amp;#xE5; tilpasse teamet underveis for &amp;#xE5; f&amp;#xE5; perfekt sammensetning. For eksempel ved &amp;#xE5; ha en god blanding av erfarne og juniorer. Det er fort gjort at fasene stagnerer etter &amp;#x201C;Norming&amp;#x201D;, eller enda v&amp;#xE6;rre; p&amp;#xE5; Storming. Da m&amp;#xE5; det tas grep.\n
  190. Tuckman har noe han kaller stages of group development, og jeg kjenner meg veldig igjen i disse stegene, s&amp;#xE5; derfor vil jeg dele det med dere. Det f&amp;#xF8;rste er &amp;#x201C;forming&amp;#x201D;: Det er som f&amp;#xF8;rste skoledag, usikre p&amp;#xE5; hverandre, lite uenighet, ingen stikker seg frem, alle lurer p&amp;#xE5; hvem som vil dominere. Neste steg er &amp;#x201C;Storming&amp;#x201D;: Da er det uenighet, konkurerende synspunkter, konfrontasjon og fare for &amp;#xE5; ikke bli enige. S&amp;#xE5;nn var det for eksempel i Digipost hvor vi hadde veldig topptung bemanning og alle hadde sterke meninger om alt. N&amp;#xE5;r vi fikk inn noen juniorer ble det endelig noen som utviklet noe. I Norming er det enighet om rammer for arbeidet, man har bestemt seg for et sett med regler, og det er relativt effektivt, typisk Scrum. S&amp;#xE5; &amp;#x201C;Performing&amp;#x201D;: Da kjenner alle hverandres svakheter og styrker og har evne til &amp;#xE5; tilpasse seg enhver oppgave og &amp;#xE5; l&amp;#xF8;se denne som et lag. Ikke v&amp;#xE6;re redd for &amp;#xE5; tilpasse teamet underveis for &amp;#xE5; f&amp;#xE5; perfekt sammensetning. For eksempel ved &amp;#xE5; ha en god blanding av erfarne og juniorer. Det er fort gjort at fasene stagnerer etter &amp;#x201C;Norming&amp;#x201D;, eller enda v&amp;#xE6;rre; p&amp;#xE5; Storming. Da m&amp;#xE5; det tas grep.\n
  191. Tuckman har noe han kaller stages of group development, og jeg kjenner meg veldig igjen i disse stegene, s&amp;#xE5; derfor vil jeg dele det med dere. Det f&amp;#xF8;rste er &amp;#x201C;forming&amp;#x201D;: Det er som f&amp;#xF8;rste skoledag, usikre p&amp;#xE5; hverandre, lite uenighet, ingen stikker seg frem, alle lurer p&amp;#xE5; hvem som vil dominere. Neste steg er &amp;#x201C;Storming&amp;#x201D;: Da er det uenighet, konkurerende synspunkter, konfrontasjon og fare for &amp;#xE5; ikke bli enige. S&amp;#xE5;nn var det for eksempel i Digipost hvor vi hadde veldig topptung bemanning og alle hadde sterke meninger om alt. N&amp;#xE5;r vi fikk inn noen juniorer ble det endelig noen som utviklet noe. I Norming er det enighet om rammer for arbeidet, man har bestemt seg for et sett med regler, og det er relativt effektivt, typisk Scrum. S&amp;#xE5; &amp;#x201C;Performing&amp;#x201D;: Da kjenner alle hverandres svakheter og styrker og har evne til &amp;#xE5; tilpasse seg enhver oppgave og &amp;#xE5; l&amp;#xF8;se denne som et lag. Ikke v&amp;#xE6;re redd for &amp;#xE5; tilpasse teamet underveis for &amp;#xE5; f&amp;#xE5; perfekt sammensetning. For eksempel ved &amp;#xE5; ha en god blanding av erfarne og juniorer. Det er fort gjort at fasene stagnerer etter &amp;#x201C;Norming&amp;#x201D;, eller enda v&amp;#xE6;rre; p&amp;#xE5; Storming. Da m&amp;#xE5; det tas grep.\n
  192. Conways law: Sier at organisasjoner er d&amp;#xF8;mt til &amp;#xE5; designe systemer som er kopier av kommunikasjonslinjene i organisasjonen.\n\nDerfor jobber vi smidig og sitter sammen med forretning hver dag.\nTrenger bare snu hodet.\nUtviklerne sitter rund ett og samme bord\nSalg/marked sitter rundt ett og samme bord.\nF&amp;#xE6;rre m&amp;#xF8;ter. Er i m&amp;#xF8;te hele tiden!\n
  193. S&amp;#xE5; er det dette med DevOps. Hva er egentlig det? Uviklere kan en del ting, s&amp;#xE5;nn som smidig utvikling, og TDD, automatisering og versjonskontroll, og drift kan en masse ting, som backup, de har DBA-er, overv&amp;#xE5;kning, og ikke minst har de rot-tilgang. Og tradisjonelt ser et utviklingsl&amp;#xF8;p s&amp;#xE5;nn ut. Kunden ber utviklerne om &amp;#xE5; gj&amp;#xF8;re noe, utviklerne gj&amp;#xF8;r det og overleverer det til drift. Drift setter det i produksjon, og det er f&amp;#xF8;rst da man f&amp;#xE5;r feedback fra brukerne. Det er selvsagt mye feil som kan oppst&amp;#xE5; p&amp;#xE5; veien, fordi man har siloer hvor man slenger ting over veggen for at neste avdeling skal ta tak i det. En testavdeling er vanligvis inni dette her ogs&amp;#xE5;, men det har jeg utelatt, fordi det burde dere v&amp;#xE6;rt kvitt for lenge siden (klikk). N&amp;#xE5;r utviklere og drift jobber sammen som et team, eller n&amp;#xE5;r det er de samme folka som utvikler og drifter, s&amp;#xE5; oppst&amp;#xE5;r en masse flotte ting (klikk). Du kan levere kontinuerlig, tester underveis, time to market blir kortere og du f&amp;#xE5;r raskere feedback. Du f&amp;#xE5;r kryssfunksjonelle team, samarbeid, og infrastruktur som kode kvalitetssikrer infrastrukturen din mye bedre enn tradisjonelt.\n
  194. S&amp;#xE5; er det dette med DevOps. Hva er egentlig det? Uviklere kan en del ting, s&amp;#xE5;nn som smidig utvikling, og TDD, automatisering og versjonskontroll, og drift kan en masse ting, som backup, de har DBA-er, overv&amp;#xE5;kning, og ikke minst har de rot-tilgang. Og tradisjonelt ser et utviklingsl&amp;#xF8;p s&amp;#xE5;nn ut. Kunden ber utviklerne om &amp;#xE5; gj&amp;#xF8;re noe, utviklerne gj&amp;#xF8;r det og overleverer det til drift. Drift setter det i produksjon, og det er f&amp;#xF8;rst da man f&amp;#xE5;r feedback fra brukerne. Det er selvsagt mye feil som kan oppst&amp;#xE5; p&amp;#xE5; veien, fordi man har siloer hvor man slenger ting over veggen for at neste avdeling skal ta tak i det. En testavdeling er vanligvis inni dette her ogs&amp;#xE5;, men det har jeg utelatt, fordi det burde dere v&amp;#xE6;rt kvitt for lenge siden (klikk). N&amp;#xE5;r utviklere og drift jobber sammen som et team, eller n&amp;#xE5;r det er de samme folka som utvikler og drifter, s&amp;#xE5; oppst&amp;#xE5;r en masse flotte ting (klikk). Du kan levere kontinuerlig, tester underveis, time to market blir kortere og du f&amp;#xE5;r raskere feedback. Du f&amp;#xE5;r kryssfunksjonelle team, samarbeid, og infrastruktur som kode kvalitetssikrer infrastrukturen din mye bedre enn tradisjonelt.\n
  195. S&amp;#xE5; er det dette med DevOps. Hva er egentlig det? Uviklere kan en del ting, s&amp;#xE5;nn som smidig utvikling, og TDD, automatisering og versjonskontroll, og drift kan en masse ting, som backup, de har DBA-er, overv&amp;#xE5;kning, og ikke minst har de rot-tilgang. Og tradisjonelt ser et utviklingsl&amp;#xF8;p s&amp;#xE5;nn ut. Kunden ber utviklerne om &amp;#xE5; gj&amp;#xF8;re noe, utviklerne gj&amp;#xF8;r det og overleverer det til drift. Drift setter det i produksjon, og det er f&amp;#xF8;rst da man f&amp;#xE5;r feedback fra brukerne. Det er selvsagt mye feil som kan oppst&amp;#xE5; p&amp;#xE5; veien, fordi man har siloer hvor man slenger ting over veggen for at neste avdeling skal ta tak i det. En testavdeling er vanligvis inni dette her ogs&amp;#xE5;, men det har jeg utelatt, fordi det burde dere v&amp;#xE6;rt kvitt for lenge siden (klikk). N&amp;#xE5;r utviklere og drift jobber sammen som et team, eller n&amp;#xE5;r det er de samme folka som utvikler og drifter, s&amp;#xE5; oppst&amp;#xE5;r en masse flotte ting (klikk). Du kan levere kontinuerlig, tester underveis, time to market blir kortere og du f&amp;#xE5;r raskere feedback. Du f&amp;#xE5;r kryssfunksjonelle team, samarbeid, og infrastruktur som kode kvalitetssikrer infrastrukturen din mye bedre enn tradisjonelt.\n
  196. S&amp;#xE5; er det dette med DevOps. Hva er egentlig det? Uviklere kan en del ting, s&amp;#xE5;nn som smidig utvikling, og TDD, automatisering og versjonskontroll, og drift kan en masse ting, som backup, de har DBA-er, overv&amp;#xE5;kning, og ikke minst har de rot-tilgang. Og tradisjonelt ser et utviklingsl&amp;#xF8;p s&amp;#xE5;nn ut. Kunden ber utviklerne om &amp;#xE5; gj&amp;#xF8;re noe, utviklerne gj&amp;#xF8;r det og overleverer det til drift. Drift setter det i produksjon, og det er f&amp;#xF8;rst da man f&amp;#xE5;r feedback fra brukerne. Det er selvsagt mye feil som kan oppst&amp;#xE5; p&amp;#xE5; veien, fordi man har siloer hvor man slenger ting over veggen for at neste avdeling skal ta tak i det. En testavdeling er vanligvis inni dette her ogs&amp;#xE5;, men det har jeg utelatt, fordi det burde dere v&amp;#xE6;rt kvitt for lenge siden (klikk). N&amp;#xE5;r utviklere og drift jobber sammen som et team, eller n&amp;#xE5;r det er de samme folka som utvikler og drifter, s&amp;#xE5; oppst&amp;#xE5;r en masse flotte ting (klikk). Du kan levere kontinuerlig, tester underveis, time to market blir kortere og du f&amp;#xE5;r raskere feedback. Du f&amp;#xE5;r kryssfunksjonelle team, samarbeid, og infrastruktur som kode kvalitetssikrer infrastrukturen din mye bedre enn tradisjonelt.\n
  197. Det har v&amp;#xE6;rt gjort mye for &amp;#xE5; forbedre m&amp;#xE5;ten vi utvikler programvare p&amp;#xE5; de siste 10 &amp;#xE5;ra.\nDet som det ikke har v&amp;#xE6;rt tilstrekkelig fokus p&amp;#xE5; er den s&amp;#xE5;kalt &amp;#x201C;last mile&amp;#x201D; &amp;#x2013; &amp;#xE5; f&amp;#xE5; ting ut i produksjon.\nOg det er f&amp;#xF8;rst da &amp;#x2013; at programvare skaper verdi. &amp;#xC5; utvikle masse ting i parallel og &amp;#xE5; vente med &amp;#xE5; f&amp;#xE5; ut ting som er ferdig er bare dumt. N&amp;#xE5;r en produkteier f&amp;#xE5;r oppleve hvordan det er &amp;#xE5; levere kontinuerlig, s&amp;#xE5; forandres hele tankesettet hans, og det &amp;#xE5;pner seg et hav av nye muligheter. Og vi slutter &amp;#xE5; v&amp;#xE6;re redd for produksjonssettinger (slide: impact)\n
  198. S&amp;#xE5;, hva er det vi &amp;#xF8;nsker at dere skal ta med dere fra dette foredraget?\n
  199. N&amp;#xE5;r man leverer kontinuerlig m&amp;#xE5; man ogs&amp;#xE5; teste kontinuerlig. Vi har ikke tid til testfaser eller overlevering til en testavdeling.\nHusk at det er mindre &amp;#xE5; teste for hver release dersom du leverer ofte,\nAlle skal teste, og det er effektivt at utviklerne tester selv.\nOg ikke glem &amp;#xE5; teste ytelse og sikkerhet.\n
  200. Eit veldig grunnleggende steg p&amp;#xE5; veien mot kontinuerlige leveranser er kontinuerlig integrasjon av kodebasen. Det er vanskelig &amp;#xE5; levere kontinuerlig n&amp;#xE5;r kodebasen f&amp;#xF8;rst blir integrert en m&amp;#xE5;ned etter at featuren er ferdig.\n\nDet vanlige er &amp;#xE5; trigge feedbackmekanismene n&amp;#xE5;r koden sjekkes inn i versjonskontroll. I tillegg m&amp;#xE5; ogs&amp;#xE5; konfigurasjonsendringer, b&amp;#xE5;de av appen og infrastrukturen, trigge disse.\n\nTil slutt har vi Deployment pipelines, som er en m&amp;#xE5;te &amp;#xE5; verifisere at en gitt releasekandidat er klar for produksjon f&amp;#xF8;r den dyttes ut.\nHusk at disse kan bygges inkrementelt, og at man ikke trenger g&amp;#xE5; all-in med utrulling I prod fra dag en for &amp;#xE5; f&amp;#xE5; noe igjen.\n
  201. Et veldig sentralt omr&amp;#xE5;de innen kontinuerlige leveranser er konfigurasjonsstyring.\n\nDet &amp;#xE5; kunne uttrykke infrastrukturen sin som kode gir stor verdi. Slik kan du enkelt provisjonere opp nye milj&amp;#xF8;er, du f&amp;#xE5;r dokumentasjon i form av lettlest kode; infrastrukturen kommer i versjonskontroll. Den blir enkel &amp;#xE5; refaktorere, og den blir ikke minst lik i alle milj&amp;#xF8;er. Men du b&amp;#xF8;r ikke deploye applikasjonen din med et provisjoneringsrammeverk. Da b&amp;#xF8;r du bruke skript.\n
  202. Det er ekstremt viktig &amp;#xE5; ha kontroll p&amp;#xE5; deployment n&amp;#xE5;r du driver med kontinuerlig leveranse. Du b&amp;#xF8;r deploye p&amp;#xE5; samme m&amp;#xE5;te til alle milj&amp;#xF8; og det skal v&amp;#xE6;re s&amp;#xE5; enkelt som &amp;#xE5; trykke p&amp;#xE5; en knapp eller kj&amp;#xF8;re ett skript. En ekstra sikkerhetsmekanisme er feature toggles hvor du kan prodsette features uten at det gj&amp;#xF8;res tilgjengelig for sluttbrukere, eller for kun et utvalg av brukerne. Nedetidfri deployment blir ogs&amp;#xE5; viktig n&amp;#xE5;r du prodsetter hyppigere og hyppigere. Og selvsagt m&amp;#xE5; det v&amp;#xE6;re enkelt &amp;#xE5; rulle frem og tilbake - ogs&amp;#xE5; mellom databaseversjoner. Det er lurt &amp;#xE5; migrere databasen uavhengig av applikasjonen. Da er det f&amp;#xE6;rre ting som kan g&amp;#xE5; galt ved hver deploy.\n
  203. Det er viktig &amp;#xE5; kunne velge den beste teknologien tilgjengelig, og denne kjennetegnes av at den er enkel &amp;#xE5; konfigurere og skripte mot. S&amp;#xE5;nn teknologi er stort sett open source, s&amp;#xE5; de som sliter med &amp;#xE5; overbevise ledelsen om dette m&amp;#xE5; st&amp;#xE5; p&amp;#xE5;. Det skal v&amp;#xE6;re enkelt &amp;#xE5; bytte ut teknologi til fordel for noe bedre, for eksempel med branch by abstraction.\n
  204. Kontinuerlige leveranser m&amp;#xE5; ha en pull-basert prosess. Det nytter ikke &amp;#xE5; drive med en masse planlegging og estimering hvis du skal levere hyppig. Koden m&amp;#xE5; alltid v&amp;#xE6;re produksjonssettbar, ellers s&amp;#xE5; kan du ikke deploye n&amp;#xE5;r du vil. Og - bust siloene! -Samarbeid med drift, eller enda bedre ha driftere eller driftskompetanse i teamet. Selvorganisering skjer ikke over natta, men med kontinuerlig forbedring og &amp;#xE5; t&amp;#xF8;rre &amp;#xE5; pr&amp;#xF8;ve, s&amp;#xE5; blir man bedre og bedre.\n
  205. Og husk: Hvis du ikke leverer kontinuerlig, s&amp;#xE5; er du egentlig ikke smidig!\n
  206. Reklame for DevOps Norway + Q &amp; A\n
  207. Q &amp; A\n
  208. \n
  209. \n